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

[Sergey Bylokhov]

On Thu, 17 Aug 2023 20:43:59 GMT, Alexey Ivanov <aivanov 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?

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

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