On Fri, 18 Aug 2023 13:24:00 GMT, Alexey Ivanov <[email protected]> wrote:
>> **Problem** >> >> Glyphs aren't stretched by applying an affine transform `scale(2, 1)` to a >> font. Instead, the space between glyphs increases. >> >> **Root Cause** >> >> Bitmaps embedded in the font are used to render the glyphs; the bitmaps >> aren't transformed, so white-space is seen which fills the requested >> horizontal size. >> >> **Fix** >> >> Disable using embedded bitmaps if horizontal transform is different from the >> vertical one. >> >> It's similar to [JDK-8204929](https://bugs.openjdk.org/browse/JDK-8204929) >> and [JDK-8255387](https://bugs.openjdk.org/browse/JDK-8255387). >> >> **Test** >> >> When embedded bitmaps are used, the right half of the image remains filled >> with the background colour. The test looks for non-white pixels in the right >> half of the image. If there are only white pixels in the right half of the >> image, the test fails; if there are other colours, the test passes. >> >> I can reproduce the problem on Windows only. Without the fix, the test >> reports 6 failures for "MS Gothic", "MS PGothic" and "MS UI Gothic" fonts >> when text antialiasing is off and when LCD antialiasing is enabled. If >> greyscale antialiasing is enabled, the glyphs are stretched as expected, >> this case was handled in JDK-8204929; it can be used as a workaround. >> >> All client tests pass. >> >> ~~The test could be *headless*, but headless systems, especially with Linux, >> don't have fonts installed. Without fonts, the test is useless, therefore I >> made it *headful*.~~ >> >> The test is *headless*. > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > Add a translucent color to the test > > …It gives correct rendering in this case because LCD antialiasing is > > replaced with greyscale one. As we already know, greyscale AA disables > > using embedded bitmaps. > > > So by way of explanation, Microsoft always used available embedded bitmaps in > LCD mode, but of course once we stretch, we aren't able to use embedded > bitmaps and it becomes LCD. Adding translucency then disables LCD so in that > case it becomes greyscale. I think the key here is _“adding translucency ~~then~~ disables LCD so in that case it becomes greyscale.”_ That is translucency converts LCD AA to greyscale AA. If LCD AA is enabled with opaque black colour, the embedded bitmaps were still used even with a transform applied. The test in this PR fails if AA is *off* and if AA is *LCD*. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15335#issuecomment-1684226926
