[OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font rendering on Windows with subpixel antialiasing

[Dmitry Batrak]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200113/88db23d6/attachment.htm>