On Thu, 17 Aug 2023 21:10:36 GMT, Sergey Bylokhov <[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*.
>
> test/jdk/java/awt/font/FontScaling/StretchedFontTest.java line 107:
> 
>> 105:         final Dimension size = getTextSize(font);
>> 106:         final BufferedImage image =
>> 107:                 new BufferedImage(size.width, size.height, 
>> TYPE_3BYTE_BGR);
> 
> t might not be related but we can test the image with alpha as well, in that 
> case I think the aa might be always disabled and/or some other code path will 
> be executed.
> 
> The test for JDK-8204929 uses the "Locale.ENGLISH" and this one "Locale.US", 
> does it matter which one is used to reproduce this bug?

> It might not be related but we can test the image with alpha as well, in that 
> case I think the aa might be always disabled and/or some other code path will 
> be executed.

This test covers the disabled AA and greyscale AA.

Do you want to include both types of buffered images in the test? Do you want 
to switch to `TYPE_4BYTE_ABGR`? Do you want to use a translucent colour for 
rendering text?

> The test for JDK-8204929 uses the "Locale.ENGLISH" and this one "Locale.US", 
> does it matter which one is used to reproduce this bug?

No, it doesn't matter here at all. Nothing would change if I didn't pass the 
locale, except that localised font names would be printed if a failure occurs.

I'll update it to `Locale.ENGLISH` for consistency with 
`GlyphRotationTest.java` from JDK-8204929.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15335#discussion_r1297779777

Reply via email to