ignore length of the last 'kern' subtable"

I noticed this warning with ttx’ing Open Sans Bold; the other styles in Open Sans don’t have this issue:

$ git clone https://github.com/google/fonts.git ; 
$ ttx fonts/apache/opensans/OpenSans-Bold.ttf ;
Dumping "OpenSans-Bold.ttf" to "OpenSans-Bold.ttx"...
Dumping 'GlyphOrder' table...
Dumping 'head' table...
Dumping 'hhea' table...
Dumping 'maxp' table...
Dumping 'OS/2' table...
Dumping 'hmtx' table...
Dumping 'cmap' table...
Dumping 'fpgm' table...
Dumping 'prep' table...
Dumping 'cvt ' table...
Dumping 'loca' table...
Dumping 'glyf' table...
/Library/Python/2.7/site-packages/fonttools-2.5-py2.7.egg/fontTools/ttLib/tables/_k_e_r_n.py:121: UserWarning: excess data in 'kern' subtable: 46628 bytes
Dumping 'kern' table...
Dumping 'name' table...
Dumping 'post' table...
Dumping 'gasp' table...
Dumping 'GDEF' table...
Dumping 'GPOS' table...
Dumping 'GSUB' table...
Dumping 'DSIG' table...
$ ttx OpenSans-Bold.ttx ;
$ ls -l OpenSans-Bold.ttf OpenSans-Bold#1.ttf ;
-rw-r--r--  1 user  group   158,720 Jul  1 20:53 OpenSans-Bold#1.ttf
-rw-r--r--  1 user  group   224,592 Jan 15 16:28 OpenSans-Bold.ttf

Since the data doesn’t round trip, I guess its a bug in Open Sans, but before reporting this to the developer, I thought I’d file an issue to better understand this error 😃

[twardoch]

The kern subtable header, according to the OpenType spec, uses a length field of type USHORT. The length field describes the subtables’s bytesize, so the maximum subtable size can be 65,535 (0xFFFF) bytes. Since the format 0 kern subtable uses 6 bytes pro kerning pair, and there is a 14-bytes long header, one kern subtable can include no more than (65,535 – 14) / 6 = 10,920 kerning pairs.

OpenSans-Bold.ttf has one kern subtable that is 112,182 (0x1B636) bytes long and has 18,964 kerning pairs. This font subtable’s length field gives the value 46,642 (0xB636) — note that the last 4 bytes of the length field are identical with the real length.

We could play this trick forever, i.e. have a subtable with 1,000,000 kerning pairs where the length field would only report the last 4 bytes of the actual bytesize — but that’s not how it works 😃

The font’s offset table uses ULONG for offset and length (so it’s free from the 64K limit of course). Some tools just read the offset and the length of the entire kern table (112,182) and then in the kern table header only check for the nTables field (the number of the subtables), and when it’s =1, they just read all kerning pairs until the end of the table. They seem to ignore the the length field of the subtable. Other tools take the subtable length seriously, and then there is a mismatch.

So this is a font bug and should be reported to the font developers. Since kern with format 0 is a legacy TrueType layout table only used in systems that don’t support OpenType Layout, the way to make valid kern tables that work cross-platform is:

1. Take your GPOS kerning and expand it to a flat list.
2. Eliminate all kerning pairs that involve at least one unencoded glyphs (it only makes sense to put kern entries for glyphs that have real Unicode value because it doesn’t work with OTL anyway).
3. Sort the list descendingly by the absolute kern value, or (if your tool has such stats) by a combination of the absolute kern value and the frequency of the occurrence of given kerning pairs in real-world texts.
4. Trim that list at 10,920 kerning pairs. In other words, limit the kern kerning to the 10,920 “most relevant” kerning pairs, whatever that means.
5. Write that kerning into the kern table.

Only fonts with one kern subtable work reliably across systems. If a kern table has multiple subtables, older Windows apps will completely ignore the entire kerning. So you have to limit the kern kerning to one subtable only.

[behdad]

Actually, in HB, I have had reverted that change accidentally.

Also, ignore this.