Problem compiling “GPOS” table Subtable Overflow in lookup: 2 type: PairAdjustment

[arrowtype]

Anya is having trouble proofing the font due to an overflowing GPOS table, which gives the following error message upon "Export":

Problem compiling “GPOS” table 
Subtable Overflow in lookup: 2 type: PairAdjustment

My general (and possibly not quite accurate) understanding of it is that the basic GPOS table can only hold a certain number of records, and kerns go in there. So, a build system can handle that “overflow” by putting that kern data somewhere else. This isn’t just a KernOn issue – I get similar messages in the builds of recursive and name sans. I think it tends to come up when a font has a lot of sources with kerning.

The Glyphs Forum only has this unhelpful post, stating that there are "a lot" of kerning pairs. https://forum.glyphsapp.com/t/gpos-error-when-exporting-variable-font/23208/3

I am guessing we have two main options…

1. Running KernOn with a lower data limit than 90kb… we could test it to see which limit allows an export. Maybe 60kb would be a good place to start?
2. Building instances with FontMake, on the command line. This isn’t too hard once you have a command to copy-paste, but it will require me to fix the features in the glyphs file more.

I also need to figure out how to find a basic count of kerning pairs.

[arrowtype]

I also need to figure out how to find a basic count of kerning pairs.

Turns out, there is a "Kerning" panel that displays this info. Shantell Sans currently has 24,974 pairs, which does seem like a lot.

I’ll see how this is changed by running KernOn at a lower limit, starting with 45kb rather than 90kb.

[arrowtype]

Nice – the library https://github.com/jenskutilek/glyphspkg will convert between glyphspackage and glyphs files!

• [x] download a version 4.35.0 of fonttools to better handle overflow
  • Attempted, but is blocked by a build error: https://github.com/googlefonts/fontmake/issues/925
• [x] also try a lower limit of kerning in kernon: check if 45kb makes exactly half the pairs, or what happens!
  • With a 45kb limit, it generates 13,095 pairs... about 52.4% as many pairs as a 90kb limit
  • With a 50kb limit, it generates 14,373 pairs
  • It builds! In Glyphs, at least.
• [x] Try a 60kb limit in kernon
  • Makes 17,254 pairs, and brings back GPOS error
  • Possible to export with the Use Extension Kerning custom parameter
  • Results in basic export OTF sizes of 170kb to 184kb
  • For context, static TTFs of Roboto are about 167kb–174kb (but they do include 1294 glyphs, vs 988 in Shantell Sans), and if I drop kerning in Roboto Regular using pyftsubset Roboto-Regular.ttf --glyphs='*' --layout-features-='kern', it eliminates 26kb of data
  • static TTFs of Source Sans Pro have about 110kb kerning for 1972 glyphs
• [x] Try adding the Use Extension Kerning custom parameter and see if that allows a GPOS overflow to be handled (see https://forum.glyphsapp.com/t/kerning-pairs-is-there-a-maximum-amount/18000/4)... it works!
• [x] Try out the mekkablue script "remove small kerning pairs" to possibly reduce number of kerns
  • Deletes about 2500–4000 pairs per master (see specifics below)
  • Takes overall pairs (with a KO limit of 60kb) from 17,254 pairs to 14,525 pairs
  • Results in files of about 166kb–180kb, but still requires Use Extension Kerning custom parameter

Small kerns deleted (Click to expand)

``` Deleting kernings smaller than 10 in Shantell Sans ExtraBold Italic... Removed 3909 kerning pairs: 2547 negative pairs 0 zero pairs 1362 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Light... Removed 2937 kerning pairs: 1613 negative pairs 0 zero pairs 1324 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans ExtraBold... Removed 4003 kerning pairs: 2745 negative pairs 0 zero pairs 1258 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Irregular Light... Removed 3306 kerning pairs: 1738 negative pairs 0 zero pairs 1568 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Irregular ExtraBold... Removed 2676 kerning pairs: 1590 negative pairs 0 zero pairs 1086 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Light Italic... Removed 2978 kerning pairs: 1856 negative pairs 0 zero pairs 1122 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Irregular Light Italic... Removed 2475 kerning pairs: 1335 negative pairs 0 zero pairs 1140 positive pairs Done. Deleting kernings smaller than 10 in Shantell Sans Irregular ExtraBold Italic... Removed 2729 kerning pairs: 1396 negative pairs 0 zero pairs 1333 positive pairs Done. ```

[arrowtype]

Experiments here took place in https://github.com/arrowtype/shantell-sans/tree/42404b878ddbc28b0af694ab575a6710522d1a4d, but I will probably abandon that branch.

[arrowtype]

It seems like we have two main choices:

1. Reducing kerning data. I find that the instances will build without any GPOS issues with a 50kb limi of kerning, but not 60kb of kerning. This may be ideal, as a quick check of Roboto (1200 glyphs) shows that Roboto Regular has only about 26kb of kerning data. A similar check of Source Sans Pro has 110kb of kerning for 2000 glyphs, so it might make sense to see if we can get about half of that for half the glyphs.
2. Allowing a lot of kerning data. If we do end up needing more than 50kb of kerning to include all important pairs, GlyphsApp offers a custom parameter, Use Extension Kerning, which will handle the GPOS overflow, and allow a build with a lot of kerning.

The full build process does add about 1/3 extra kerning data to many instances, by adding in a lot of alt glyphs. So, that might be one reason to set a reasonable limit in KernOn (like 50kb), then proof it to find any important misses, and add those as models or independent pairs. I'd like to test this approach (option 1, above) first.

[arrowtype]

For now, I think it makes sense to just use a KernOn limit of 50kb, and we can change if we find a reason to.