RFR: 8312555: Hieroglyphs aren't stretched by AffineTransform.scale(2, 1)

[Alexey Ivanov]

On Thu, 17 Aug 2023 21:10:36 GMT, Sergey Bylokhov <serb at openjdk.org> 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