Hello, I'd like to submit a patch for JDK-8236996. I'm not a Committer, so I'll need someone to sponsor this change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8236996 Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/ The problem described in JDK-8236996 is from a group of issues (see also e.g. JDK-8078382 and JDK-8192972), where JDK uses one font to perform char-to-glyph conversion, but GDI, when asked to render the glyph is picking a different font, leading to completely random glyphs being rendered, as char-to-glyph mapping obviously differs for different fonts. Specific version of Roboto font, mentioned in JDK-8236996, is most probably causing the issue because it's not following the naming guidelines from OpenType specification ( https://docs.microsoft.com/en-us/typography/opentype/spec/name), having more than 4 variants (regular, bold, italic and bold italic) with the same 'Font Family name' (name ID = 1). So, GDI gets confused and picks Roboto Black for rendering, when asked to choose a regular font from Roboto family (Roboto Black having weight of 400, just like Roboto Regular, probably adds to the confusion). But the reasoning, given above, about the issue cause is only a guess. GDI is not an open-source subsystem, so we cannot know for sure how it selects the font for rendering, and cannot implement matching logic in JDK. Ideally, we'd want to select the font by specifying its file path, but that's not possible with GDI. Luckily, it allows us to query file data for the selected font using GetFontData function ( https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata), which we can use to validate that the selected font is the one we need. The proposed solution is to check the file size of the font, selected by GDI, before using it for rendering. If a mismatch is detected, fallback to FreeType is performed. It can produce a somewhat different glyph representation, but, at least, the correct glyph will be rendered. For members of font collections, file size for validation is calculated in a special way, in accordance with GetFontData logic described in the documentation. I've verified that it works for font collections bundled with Windows 10. As for performance impact, during testing I didn't observe average glyph generation time increase of more than 15%. Taking glyph caching into account, it shouldn't be that significant for typical UI applications, I think. Performance impact can be made even smaller - by performing the validation only once per font, but, I believe, having a Java application always render correct glyphs (even if fonts are added or removed while application is running) is more important. Proposed patch doesn't add any tests, as reproducing the issue requires installation of fonts. Existing automated OpenJDK tests pass after the fix. Proposed approach has been used in JetBrains Runtime without known issues for about 3 months in testing and for about 1 month in production. Best regards, Dmitry Batrak
