On Wed, 20 Sep 2023 14:07:17 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
>> **Root cause** >> >> The _Baekmuk Headline_ font maps `\u6f22` (漢) to glyph id 16950 which has >> zero length. >> >> The test fails if the right half of the image with the rendered glyph >> contains only pixels of background colour. In this case, the left half of >> the image is also blank. It's somewhat false positive because of the broken >> font. >> >> **Fix** >> >> Ignore fonts which don't render the glyph correctly. If the left half of the >> image contains pixels of the background colour only, it is expected that the >> right half also contains background-coloured pixels only. >> >> The updated test does not fail with the _Baekmuk Headline_ font. It still >> detects the original problem and fails on builds without the fix for >> [JDK-8312555](https://bugs.openjdk.org/browse/JDK-8312555). > > Alexey Ivanov has updated the pull request incrementally with one additional > commit since the last revision: > > 8316206: Use GlyphVector.getVisualBounds().isEmpty() > > Filter out broken fonts by GlyphVector.getVisualBounds().isEmpty() > I was thinking of a more direct font-oriented verification like this > > ```java > import java.awt.*; > import java.awt.font.*; > > public class GO { > public static void main(String args[]) { > Font font = new Font(Font.SANS_SERIF, Font.PLAIN, 20); > FontRenderContext frc = new FontRenderContext(null, false, false); > GlyphVector gv = font.createGlyphVector(frc, "o"); > boolean empty = gv.getVisualBounds().isEmpty(); > System.out.println("empty="+empty); > } > } > ``` > ```text > % java GO > empty=true > ``` @prrace Thank you! It's a much cleaner approach. I've updated the PR. When I run the test on Linux with, I get the a diagnostic message: ~/work/jdk-dev$ ~/dev/tools/jdk20/bin/java test/jdk/java/awt/Font/FontScaling/StretchedFontTest.java Broken font: Baekmuk Headline ------------- PR Comment: https://git.openjdk.org/jdk/pull/15818#issuecomment-1727824472
