There’s a mekkablue script called Kern Flattener. It does exactly that, including subsetting your kerning. It will duplicate your font so you don’t need to worry about data loss in your original file.
1 Like
Fantastic thanks a lot, both of you!
Hello again. What is the maximum size of the “old style kern table”? I am getting an error on exporting with my current kerning (2.2k pairs, 8kB).
Sadly, Kern Flattener doesn’t work for small caps (unencoded glyphs in general). Any idea for a quick way to remedy this? Not quite looking forward to digging into the Kern Flattener code to accomodate for these glyphs. I don’t quite understand what’s going on in lines 166–168. Thanks!
To export a kern table all group kerning is flattened, so 2000 (class) pairs will most likely exceed the limit. I just had a look at the spec and it seems that the maximum number of flattened pairs is 10920.
But looking at the spec I understood that this limit is per subtable and that one can add several of them. This blows up the file size quite a bit but at least will work.
Thank you. I will continue experimenting.
One more question: In the Kern Flattener script, the parameter used is called Export kern Table. Earlier, you mentioned it being Write Kern Table. Which is correct? Export kern Table seems to work (except that I am constantly getting “too many kerning pairs for old-style kern table”).
I added the multiple subtables and an API that allows to integrate an subsetting into the export process directly into Glyphs 3.2
Export kern Table is better but the other still works, too.
Though the kern table can hold multiple subtables, no known app uses more than the first one. So it makes no sense to generate more than 10920 kern pairs.
1 Like
In which scenario can you not use proper GPOS kerning, but still use small cap OT features?
I just tried and Word for Mac seems to read more than one subtable. I’ll have another look.
I’m trying to make my font work with a really ancient layout engine, pre-DirectWrite, GDI-based. This is why I need to export the kerning without multiple lookups.
And my font has small caps, for which I would like to keep the kerning. But no worries, I modified the Kern Flattener to accomodate for my small caps 
Correction from my side: It appears I am actually just in need of a kerning table using one single lookup. Glyphs appears to write out multiple lookups for the kerning table, I suspect for ease of code (certain scripts like Arabic might require certain flags).
My current solution is to manually copy the kerning code out of the features.fea, delete the lookout separation, then paste the kerning code into a kern feature added to Font Info > Features. I have to do this separately for each instance, as the kern code of course changes. Since the Add Feature/Replace Feature for kerning is still broken, this is the only workaround I can currently think of.
Please don’t confuse kern table with kern features. Both have subtables but only the later has lookups.
Yes, my mistake. This is the first time I’m having to dig into these things. I confused the kern table with the kern feature, in any case, the software I’m trying to cater to is unable to read a kern feature with more than one lookup. Can you maybe suggest a way of generating kerning with only one lookup? Thanks a lot!
This problem is in most of the Office apps. So it is not so ancient as you think.
It is on my list have a look if I can reduce the number of lookups.
Thank you. For the time being, just getting Add Feature or Replace Feature custom parameters to work would be an immense help 
The “Add Feature” should work in Glyphs 3.2.
hi! i had a problem with this today and i solved it, so i dont need help, but for future people looking up solutions to their problems, i figured i’d say what happened to me, just in case someone needs to see it in the future:
i had a font that was behaving inconsistently (failing to kern) across different programs that require this old-style kern table (namely flash 2017.5 vs 2018) and the problem turned out to be that i’d done kerning on an emoji.
i sacrificed that and then things started working consistently again. i shouldnt have needed kerning on an emoji in the first place, but it makes sense that there’d be some kind of conflict for these old tables and more recent unicode additions like emojis. i guess.
also, i was using Glyphs 2.x, so if this is already fixed anyway, my bad for bringing it up!