TrueType-based fonts and post table version 3.0

Jens Kutilek

A word of warning ...

It’s really tempting to switch the post table version to 3.0, which then doesn’t store any glyph names in the font, saving file size especially for web fonts.

But for TrueType-based fonts (also packaged in WOFF, WOFF2), doing this will prevent the macOS autohinting from doing its job. Fuzzy contours and uneven stem weights are the result.

I was reminded of this after wondering why some fonts from a well-known monopolist didn’t look very good in the browser.

Mike Duggan

Mac OS Autohinting? Can you give any details on this? 

Georg Seifert

MacOS is doing VERY soft autohinting on the fly. There is no way to influence it (I asked).

Jens Kutilek

Oh, you can mess it up by using post table version 3. Will post some screenshots when I get home.

Deleted Account

Speeding up the throughput by removing the glyph names causes the font to render to quickly.

Jens Kutilek

Here’s a comparison as animated gif. The x-height and cap height alignments don’t work with post table version 3.



The effect is not visible in all sizes (shown is 16 px).

Jens Kutilek

I had a more impressive example with a monolinear thin small cap font, but don’t have the font here to reproduce it. In that case, the stem weights between top and base horizontal stems were noticeably off, like 1 vs. 2 pixels.

Mike Duggan

So this happens on latest Mac OS, on non Retina displays? Only useful for that purpose right? 

Jens Kutilek

Yes, latest macOS and non Retina. In my limited tests, I found differences up to sizes of 18px, so it’s probably relevant only on non Retina displays.

Jens Kutilek

Here is another case, a bit different, because it is an OT-CFF font, but with wrong glyph names: the small caps glyphs have been encoded as lowercase letters, but their glyph names kept the UC base name and .sc suffix.



When the glyphs are renamed to their proper names, the screen display improves. Again, differences appear only up to 18 px font size.

Khaled Hosny

Does this autohinting stuff affect other scripts or only Latin?

SiDaniels

Amazin!

John Hudson

Yup. 2016, and Apple are still apparently relying on glyph names for some functions.

Nir Lahad

Apple's TrueType Reference Manual advise against using `post` table format 3:

Apple recommends against using 'post' table format 3 under most circumstances, as it can create problems with some printer drivers and PDF documents. The savings in disk space usually does not justify the potential loss in functionality.

Khaled Hosny

One would think that such applications would just create dummy glyph names on the fly. Actually the only PDF producer I’m familiar with its code will guess glyph names in this case based on cmap mappings and use dummy names like glyphXXXX if there is ambiguity or unencoded glyphs.

Hin-Tak Leung

Filed https://github.com/Microsoft/Font-Validator/issues/47


The main files to modify are these two:
https://github.com/HinTak/Font-Validator/blob/master/OTFontFileVal/val_post.cs

https://github.com/HinTak/Font-Validator/blob/master/GenerateFValData/OurData.xml

The change is simple enough that somebody else can have a go at it

SiDaniels

I'd be willing to bet a pint that the Apple guidance is at least 15 years old, probably 20. ;-)

Jens Kutilek

Khaled Hosny said:

Does this autohinting stuff affect other scripts or only Latin?

Sorry, I haven’t tested other scripts yet.