I've gotten this message, trying to generate fonts with far fewer kerning pairs. Maybe FontLab ought to pay more attention to fixing structural flaws, rather than adding a lot of new and unasked-for functions and features, which will probably involve a steep learning curve. IMHO.

You shouldn’n mix different scripts in one kerning class, it may cause an increasing of unnecessary kerning pairs when changing class kerning into plain kerning (because some applications don’t support class kerning). Also I remember Miguel Saosa wrote that when you have a large character set (more than 2000 glyphs) and different scripts you have to optimise kern feature, for example your classes for different scripts shouldn’t mix in the class panel: first all latin classes should go and after them all cyrillic ones or first cyrillic and then latin, but don’t mix them. I think this may be the reason for your kern feature overflow. I had kern feature overflow too, and after rearranging of classes my feature compiled. Also check if there any glyphs that belong to more then one class with one side. Hope it helps.

This error generally occurs because the contents of the kern feature lookups overflow the size limit of the GPOS subtable. The way to fix it is to break up the kern feature into a number of smaller subtables. This can be done manually in the feature code, but for best results I recommend licensing Karsten Luecke's excellent KLTF Make Kern Feature script, which analyses your kerning data and generates the most efficient kern feature code with appropriate subtable breaks.

See also http://www.kltf.de/downloads/KLTF-MakeKernFeature.pdf

The experts at FSI -who were going to be doing the final production on Ernestine*- warned me early on to keep the kerning in my Armenian component lean, since the font overall had so many characters. I ended up staying under 300, which was a bit disappointing**. Somebody somewhere should fix this problem.

* http://ernestinefont.com/

** As a comparison, I ended up with about 800 in a third-party Armenian-component spacing & kerning job I just finished.

John, I assume Luecke's script doesn't circumvent all such limits?

hhp

I assume Luecke's script doesn't circumvent all such limits?

I'm not sure what you mean. It circumvents the kern subtable overflow limit, which is what it is designed to do. I've used it -- via the VOLT export option -- on some very large fonts with the class+exception equivalent of >100,000 flat kern pairs.

And the reason FSI for one doesn't use this technique/script?

Sort of related:
You know what's funny BTW? The guy who made Maven* being so proud that it has 6,500 kerns, except pretty much everything is (most likely auto) kerned... and it still sets like junk. Bah, who needs to worry about sidebearings anyway! :-/

* http://vissol.co.uk/mavenpro/

hhp

And the reason FSI for one doesn't use this technique/script?

No idea. The other way to do it is manually, and most people use trial and error or best guess about where to put the subtable breaks.

Was the kern subtable overflow limit set in the beginning before we had so many extremely large fonts to work with?

I have also used Karsten's script, he also recommends some particular naming conventions for classes which helps minimize the problem.

Karsten"s script has saved my bacon for years! Best additional purchase I have made for Fontlab.

Chris: Was the kern subtable overflow limit set in the beginning before we had so many extremely large fonts to work with?

It's not particular to the kern feature subtable, it just happens that this feature is the most common to exceed the subtable limit. The limit is part of the basic architecture of TrueType, in which there is a 64k size restriction on table size. The extension mechanism in the OpenType Layout tables enables this to be overcome, but each subtable within the mechanism is still limited to 64k.

Recently, I hit the GPOS subtable limit with a mark positioning feature, and presently I have no tool to perform the kind of subtable break that Karsten does for the kern feature. I had to manually optimise my mark feature contents to fit within a single subtable.

ouch!

Somebody somewhere should fix this problem.

Which is is what I did.

John, I assume Luecke's script doesn't circumvent all such limits?

It does not 'circumvent' any limits. It simply breaks up data into junks small enough to stay within subtable-size limitations, as a consequence, offset-value limitations.

And the reason FSI for one doesn't use this technique/script?

Only FSI knows.

"The limit is part of the basic architecture of TrueType..."

All good, but it's immediately a limit on the sfnt that causes the overflow, so it's in the architecture of all the wrappers wrap.

The less immediate issue is that the gpos provides control over glyph placement for sophisticated text layout and the rendering of each script and language system that a font supports, while the kerning table contains the values that control the inter-character spacing for the glyphs in a font.

Thank you Karsten!

hhp

Thanks again, Karsten, for your many helpful tools and suggestions!

David, are you referring to the 'kern' table? That comes with numerous limitations of it's own, and trying to separate 'inter-character spacing for the glyphs in a font' from 'glyph placement for ... the rendering of each script and language system that a font supports' isn't an option for many of those scripts and languages.

Is there another kind?

There's GPOS kerning, hence my query as to your meaning, because your statement appeared to make a distinction between GPOS and kerning, and the phrase 'kerning table', as distinct from the specific 'kern' table, could refer to a GPOS kern feature subtable (the thing that goes boom and prompts threads like this one).

As far as I'm concerned the 'kern' table is a legacy data format; it's been a decade since I've been asked to ship a font containing one, and even then it was only a subset of the kerning provided in the GPOS table, and only included for backwards compatibility. In most of the fonts I make, the kern table simply can't do what I need kerning to be able to do.

And what is that?

As far as the name, I call it what MS documentation calls it "the kerning table". Hope that's clear.

For most of the scripts I work with, contextual kerning is a requirement, not an option. This is even the case in Latin fonts that support GPOS mark positioning. Consider that the kerning of the glyph pair Te is unlikely to be appropriate if the e is carrying a combining mark glyph above it. I'm also mostly working with glyph sets in which class kerning is essential to handle the number of glyphs involved; it isn't unusual for flattened kerning to be >65,000 pairs in one font.

As far as the name, I call it what MS documentation calls it "the kerning table".

Ah, you mean the Kerning table.