Fwd: Issue 1041569 in chromium: Poor rendering quality of variable fonts

[Dave Crossland]

Fun stuff

---------- Forwarded message ---------
From: raph.levien via monorail <monorail+v2...@chromium.org>
Date: Sat, Jul 25, 2020, 11:57 AM
Subject: Issue 1041569 in chromium: Poor rendering quality of variable fonts
To: <dcros...@google.com>

Comment #9 on issue 1041569 by raph....@gmail.com: Poor rendering quality of variable fonts
https://bugs.chromium.org/p/chromium/issues/detail?id=1041569#c9

I have some preliminary results on this. The analysis is divided into two parts.

First, the quantization to integer widths when the FreeType path is selected. This is because of a mismatch in the way the hinting level is interpreted between platforms. With FreeType rendering, SkFontHinting::kNormal is interpreted as quantizing widths to integers (both stems and metrics), while kSlight is basically vertical-only hints (see https://www.freetype.org/freetype2/docs/text-rendering-general.html for a deeper explanation). Due to a poorly-reasoned hack in SkFontHost_FreeType, kFull actually implies *less* hinting than kNormal when LCD subpixel rendering is selected. As a result, upstream configuration on Linux reliably sets modes other than kNormal. (Note: I haven't done extensive testing on Linux. Also note, font rendering quality expectations on Linux are different than on Windows).

Conversely, on Windows, with the DirectWrite rendering path, widths are (as far as I can tell) never quantized, so upstream configuration defaults to kNormal. (I should note that upstream configuration is very complicated, starting from reading various configuration options from the system, and then with opportunities to be overridden by CSS like -webkit-font-smoothing). Thus, when the FreeType rendering path is selected (which currently happens when a QueryInterface of IDWriteFontFace5 fails), kNormal is interpreted as integer quantization, mismatching what DirectWrite would do.

I don't yet have a solid recommendation for the solution, as the configuration chain is quite long, and this could be fixed at any point from converting system configuration to FontRenderParams, all the way to converting SkFontHinting to FT_LOAD_TARGET flags. The most principled approach would be to make the interpretation of SkFontHinting settings consistent across the back-ends, but due to Hyrum's Law there would be considerable risk of breaking other Skia clients. A lighter touch would be to make FreeType rendering consistent with DirectWrite *on Windows,* but this further complicates the thicket of configuration options. And the lowest risk would be working around the Skia-level inconsistency by setting upstream configuration to give the desired result. Because of the hacks in SkFontHost_FreeType, that would be kSlight when LCD subpixel is not selected, and kFull when it is. (Note: an additional question to investigated is whether FT_LOAD_TARGET_LCD is different enough from FT_LOAD_TARGET_LIGHT that it's worth bothering. If not, then just setting FontRenderParams::HINTING_SLIGHT rather than HINTING_MEDIUM in font_render_params_win might be the simplest fix, but then we'd also need to check whether CSS-originated overrides might cause other regressions).

The second part of the analysis is whether client-side autohinting is a viable rendering strategy for variable fonts. Preliminary testing (mostly with Inconsolata) is encouraging. If further testing bears this out, then my recommendation will be to select the FreeType path not only when the platform is incapable of variable font rendering (ie the QueryInterface fails), but also when the font *would be* rendered with autohinting. This is true when autohinting is enabled and the font ships without hints. Obviously this recommendation is dependent on the first, as otherwise overly heavy-handed hinting would be an unacceptable regression.

For this second recommendation, I will gather screenshots from multiple fonts and an analysis of the hinting quality. Being able to rely on client-side autohinting would have many significant advantages for web font services, both network traffic savings from not having to send hints, and also much improved design processes for creating variable fonts, as hinting to make DirectWrite happy is a tedious, manual process relying on proprietary tools.

--
You received this message because:
1. You were specifically CC'd on the issue

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

Reply to this email to add a comment or make updates.