Different OpenType/CFF behavior on Windows 10 with 'gasp' table

[Ken Lunde]

All (but probably more directed to our friends at Microsoft),

One of our more important development partners has observed different rendering behavior on Windows 10, such as in various browsers (Chrome, Firefox, and Edge), when an OpenType/CFF font includes a 'gasp' table. This was also confirmed after modifying the following example app, though they stated that the differences were less striking:

https://github.com/Microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/multimedia/DirectWrite/SimpleHelloWorld

As far as the OpenType Specification is concerned, 'gasp' is a TrueType-specific table, as it is listed among the "Tables Related to TrueType Outlines":

https://docs.microsoft.com/en-us/typography/opentype/spec/otff#tables-related-to-truetype-outlines

Interestingly, the description of the table itself doesn't draw attention to this, which is likely why this developer tried this in the first place. Now that the proverbial genie is out of the bottle, they are now very curious why there are rendering differences.

They suspect that DirectWrite may be sensitive to the presence of the 'gasp' table in OpenType/CFF (aka non-TrueType) fonts, which matches their observations. To my eyes, the rendering looks better without the table, so part of me naturally wonders why they even tried this. (Answer: They were not aware that it is a TrueType-specific table.)

In closing, I am wondering whether "unknown" or "unpredictable" is the expected behavior if an OpenType/CFF font includes a 'gasp' table. If not, some guidance would be helpful, so that I can pass it along to them.

Regards...

-- Ken