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

[Phil Race]

So this is a workaround for a buggy font that doesn't play well with GDI ?

It does rely on the fonts always being different sizes which is highly 
likely if not guaranteed.
I suppose it is OK so long as we aren't getting any "false" positives.

What I mean is that almost no one will have these Roboto fonts 
installed, so the fix
is solving a problem they don't have, but if it is wrong in some way, 
then they could lose
GDI rendering of LCD glyphs and that could affect a lot of people.

So have you tested this with the full set of Windows 10 fonts - 
including Indic, CJK, etc  - to be sure
there are no cases where it fails for these or other spurious failures.

 > As for performance impact, during testing I didn't observe average 
glyph generation time increase of more than 15%.

Since you aren't retrieving the data, just asking what the size is, I'd 
expect it to be unmeasurable.

-phil.

On 1/13/20 1:25 AM, Dmitry Batrak wrote:
> 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