Ensure all TTFs have v2 'post' tables #215

davelab6 · 2016-02-19T14:32:17Z

https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6post.html says,

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.

Its not clear to me if this is still a valid concern, but https://forum.glyphsapp.com/t/custom-parameter-for-post-table-type-2/ is from June 2015 so it seems to still be relevant.

Therefore all the TTFs in this repo should have v2 post tables. (They should be flipped to v3 when served to web browsers where file size savings do matter, and the fontTools subsetter does use v3.)

At the moment the TTFs in github have a mix of v2/v3 post tables, around 88:12%.

I determined this with a simple python and shell script to print the post table version,

import sys
from fontTools.ttLib import TTFont
fontfile = sys.argv[1]
font = TTFont(fontfile)
print str(font['post'].formatType), fontfile

$ for font in `find . -name \*.\*tf -print`; do \
     python ~/post-format.py $font >> post-version.txt; \
   done;
$ cat post-version.txt | sort | cut -d\  -f1 | uniq -c
1554 2.0
 182 3.0

Probably the TTFs in github with v3 POST tables have it that way because they were converted from CFFs, which is likely bad as it bloats filesize.

The text was updated successfully, but these errors were encountered:

khaledhosny · 2016-07-07T00:44:05Z

I don’t think it makes much sense to require version 2 post table on the Web, Apple reference is referring to PDF generation which is an irrelevant use case here, and even this should be handled by any PDF generation tool worthy its salt (generating glyph names when embedding the font in PDF). The Glyphs forum discussion does not even mention what scenarios requires post version 2 and I highly doubt it will have anything to do with the use on the web.

For some fonts the difference can be huge (version 2 and 3, respectively):

du -h --apparent-size amiri-regular#*.ttf
534K    amiri-regular#1.ttf
400K    amiri-regular#2.ttf

davelab6 · 2016-07-07T02:21:00Z

The TTFs that the Google Fonts API ingests are intended for desktop usage.

The API can convert post tables from type 2 to type 3, but the TTFs should have the widest utility; thus type 2.

khaledhosny · 2016-07-07T02:28:58Z

Makes sense.

davelab6 · 2018-02-23T16:34:29Z

Note that cjk and maybe larger filesize fonts for other scripts can have v3 because the PDF text extraction possible with v2 is probably Latin only, and filesize reduction in v3 is good

thundernixon · 2019-01-15T03:19:30Z

@davelab6 do you know of a good way to change the post table version? Signika currently has version 3.

thundernixon · 2019-01-15T03:29:03Z

Ah, I see. I am getting this WARN on a subset SC font which has been subset by fontTools, and as you say in the opening comment,

They should be flipped to v3 when served to web browsers where file size savings do matter, and the fontTools subsetter does use v3.

So, I'll leave it unless there's a good reason not to.

anthrotype · 2019-01-15T16:10:34Z

fonttools subset will keep the glyph names if you pass --glyph-names option

converting from post format 2 to 3 is trivial (just set ttFont["post"].formatType = 3.0 and save), whereas the other way around the names have already been deleted from the font binary, so you'll have to get it from somewhere else (e.g. public.postscriptNames list in UFO lib), and call ttFont.setGlyphOrder([... your list of glyph names ...]) then compile/save the ttFont.

thundernixon · 2019-01-15T17:33:29Z

Passing the --glyph-names option solved it!

Thanks for pointing that out, @anthrotype.

miguelsousa · 2019-09-17T17:58:02Z

The check com.google.fonts/check/post_table_version (fontbakery v0.7.12) gives the following result when ran on a variable OTF:

FAIL: Post table should be version 3 instead of 2.0. More info at https://github.com/google/fonts/issues/215

The CFF2 table does not contain glyph names, so variable OTFs should be allowed to use post table version 2.

davelab6 · 2019-09-18T13:24:23Z

Thanks @miguelsousa :) The majority of the com.google.fonts/check checks are for TTFs; I'll repost that in the fontbakery issue tracker now :)

felipesanches · 2019-09-18T13:46:56Z

thanks, @davelab6 and @miguelsousa

felipesanches · 2020-02-18T13:46:21Z

As of 9b4b790, Wed Feb 12, 2020, the font files below are the 5% of the collection with a version 3 post table: