MM Typeface and [FATAL] GPOS feature 'kern' causes overflow of offset to a subtable

kateliev's picture

Hi everyone,

I’m am stuck in the following peculiar situation:

I have a MM typeface, composed from two masters (weight – wt0 and wt1). After careful kerning (started four times from scratch) I ended with 6000 kern pairs, which include Latin, Cyrillic, small caps for both, different numeral sets, fractions and etc. – it’s a big typeface. When building the kern feature and then compiling the font everything works just fine. But, if I split the typeface to the desired instances, for fine tuning and polishing, it seems that after updating the kern feature, every font does not compile (excluding the equivalent of wt0) - ending with “[FATAL] GPOS feature 'kern' causes overflow of offset to a subtable”. The peculiar thing is that, if I split the typeface only to the two masters wt0 and wt1, wt0 compiles ok with 6000 pairs. On the other hand wt1 does return “GPOS overflow..” every time, until I reduce the pairs to approximately 4420, which is -1600 pairs short.

Any ideas what could cause this kind of behavior? Thank you in advance!

note: I am using Fontlab 5.04 win. My class kerning is revolving around the idea to have class for every glyph (not shape type) that is part of composite + Cyrillic : A’ Atilte Adireseis…..cyrillic A…etc. Classes are composed from mixed script characters, so I could only kern for differences.

oldnick's picture

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.

Yulia's picture

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.

John Hudson's picture

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

hrant's picture

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

John Hudson's picture

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.

hrant's picture

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

John Hudson's picture

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.

dezcom's picture

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.

Charles_borges_de_oliveira's picture

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

John Hudson's picture

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.

dezcom's picture

ouch!

k.l.'s picture

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.

dberlow's picture

"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.

hrant's picture

Thank you Karsten!

hhp

dezcom's picture

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

John Hudson's picture

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.

dberlow's picture

Is there another kind?

John Hudson's picture

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.

dberlow's picture

And what is that?

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

John Hudson's picture

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.

Syndicate content Syndicate content