[ft-devel] Experimental: v38 interpreter with minimal backwards compatibility mode and linear advance widths

[Nikolaus Waxweiler]

Hey list,
so Derek's mail made me look at the TrueType engine again.

The attached patch does the following:
- v38 is the default version
- implement GETINFO selector bits 6, 10, 11 and 12 for subpixel_hinting 
(v38 -> always on), subpixel_positioning (v38 -> always on), symmetrical 
smoothing (always on), grayscale_cleartype (on unless 
FT_LOAD_TARGET_LCD(_V))
- Minimal backwards compatibility mode: stop all x-Movement in 
Direct_Move(), Direct_Move_X() and Move_Zp2_Point() iff freedom vector 
is parallel to x-axis. This adds 3 lines and does 90% of the work to 
make fonts intended for ClearType rendering render well. Most fonts out 
there that are intended for ClearType rendering actually rely on the 
hacks of Microsoft's backwards compatibility mode to render well. This 
hack does the job for most ClearType-able fonts, even for Microsoft's 
flagships such as Calibri, Cambria and Segoe UI. Pre-ClearType fonts 
like Arial and Times fare much worse. Also, additional cvt cutin/minimum 
distance stuff Infinality did (did not systematically check if this 
needs to be added to more places).
- Fonts can turn off backwards compatibility via Microsoft's INSTCTRL 
spell. On my Windows 10 Update 1511 installation, I found Constantia, 
Corbel, Sitka, Malgun Gothic, Microsoft JhengHei (Bold and UI Bold), 
Microsoft YaHei (Bold and UI Bold), SimSun, NSimSun and Yu Gothic that 
do it.
- Changes to the (horizontal?) advance width are shorted out if on v38.

Apply on top of unchanged source, leave 
TT_CONFIG_OPTION_SUBPIXEL_HINTING off.

The patch is meant as a request for comments. I wanted to see if I could 
find a minimal portion of Infinality's work that would do a reasonable 
job for most webfonts I come across. It is also a sort-of preparation 
for a stem-darkening-able light mode for the TT engine. I personally am 
not fond of the complexity it brought to the code base and there is no 
one to do anything about it. If there is a way to sort out pre-ClearType 
fonts and refer them to the autohinter instead, how about going with a 
patch like this? The configurability would be gone but I personally 
think that much of it is misguided flexibility and unneeded baggage for 
pre-ClearType fonts. I'd much rather see improvements to the autohinter 
and a refactoring of the CFF grid-fitter into its' own module[1].

Known problems:
- Incompatible with #define TT_CONFIG_OPTION_SUBPIXEL_HINTING
- "Classically" hinted fonts like Arial, Times and DejaVu render ugly 
and with some glitches. Granted, I did nothing about delta hints and 
such yet and haven't looked closely at other Infinality changes. Is 
there any known way to detect pre-ClearType fonts and separate them from 
fonts that render nicely in ClearType but depend on MS' hacks?
- Switching from v38 to v35 in ftview seems to hang something, haven't 
looked into it yet
- Some light fonts render less well, some ClearType-able fonts have glitches
- Rendering results by their nature slightly sharper than what the 
autohinter/CFF engine put out. Might not harmonize well.
- Not suited for tricky fonts unless they go native ClearType? I have 
none to test.

[1]: I had a look at it and it seems to be intimately tied to the CFF 
engine. Reworking it into its' own module seems a non-trivial task.

minimal_v38_interpreter.patch
Description: Text Data