Hello. I hope you are having a good week. Friends, I encountered such an error in FontLab. I can't find any reason. Maybe your have an idea?
FEA compiler error: [F] In feature 'kern' lookup 'KERN_LTR' positioning rules cause an offset overflow (0x10094) to a lookup subtable
FEA compiler error: [F] Fatal error in font "font" in file "features" at line 13242
Features compilation failed. Trying without the [kern] feature
Comments
You can use an "extension" lookup to work around this. Or split your kerning into explicit separate lookups. Or, rework your kerning classes to have fewer of them.
What version of FontLab are you using btw? IIRC the newer versions will automatically invoke extension lookups when appropriate.
Thus, even if one character has only one kern (most likely X), make a kerning class for it!
I thought exactly as you said. I thought there would be a faster solution here. In the meantime, I solved the problem.
A typical GPOS kerning structure at the table level consists of a series of subtable lookups:
- glyph to glyph
- glyph to class
- class to glyph
- class to class
Subtable lookups are processed by OTL engines in sequence until a matching input is found, the positioning is applied, and then the remainder of the subtable lookups are skipped. This is what enables the glyph-to-glyph and glyph-to-mark—and vice versa—to be processed as exceptions that override the class-to-class kerning: they are processed first and then the subsequent kerning subtable lookups are skipped.When any of those subtable lookups overruns the max size, it needs to be split into further subtables. So, for example, one might need something like
- glyph to glyph 1
- glyph to glyph 2
- glyph to class
- class to glyph
- class to class
if the glyph-to-glyph kerning exceeds the max subtable size.What you are doing when you assign a single glyph to a class as you describe is moving the kerning associated with that glyph out of the glyph-to-glyph kerning subtable, and putting it into the subsequent glyph-to-class, class-to-glyph, and class-to-class subtables. And in many cases that may indeed avoid maxing out the size of the glyph-to-glyph subtable, and the subtable lookups involving classes will always tend to be smaller than glyph-to-glyph subtables, which explains why you’ve had success with this method.
But any of those typical GPOS kerning subtable lookups can overrun the max size, given a large enough font, complex enough shapes, and sufficient quantity of classes. This is more likely in kerning some scripts than others.
So I would say your mechanism is a valid one in many cases—and has the benefit of readying the kerning source for future additional glyphs that might be added to those single-glyph classes—, but isn’t guaranteed to avoid the subtable overrun problem.
<single> <single>
<single> <class>
<class> <single>
<class> <class>
Each subtable may contain only one of these formats. For example, if alphabetical sorting mixes the <single> <single> and <single> <class> entries, the subtable is broken, i.e., the spacing does not work if the type of entry differs from that of the beginning of the subtable. The compiler may also attempt to split into subtables without regard to the logic of the groups, breaking the kerning. The number of subtables does not seem to matter much, but the specifications state that many subtables increase the font-file size. A possible approach is:
• lookup;
<single> <single>
– subtable;
<single> <class>
– subtable;
<class> <single>
• lookup;
<class> <class>
and subsequently to separate each character (including UC, LC, SC) into subtables, for example:
@A_UC @A_UC <0 0 0 0>;
@A_LC @A_LC <0 0 0 0>;
@A_SC @A_SC <0 0 0 0>;
– subtable;
@B_UC @B_UC <0 0 0 0>;
@B_LC @B_LC <0 0 0 0>;
@B_SC @B_SC <0 0 0 0>;
– subtable;
@C_UC @C_UC <0 0 0 0>;
@C_LC @C_LC <0 0 0 0>;
@C_SC @C_SC <0 0 0 0>;
etc.
The pairs <single> <single>, <single> <class>, <class> <single> must be compiled first. This makes sense if one uses enumeration pairs, that is, exceptions to the class definitions. In theory, the <single> <single>, <single> <class> and <class> <single> pairs do not need to be ‘physically’ placed on top. If there is a lookup format, the order of the lookups in the features file will determine the order of processing by the compiler, of course. Empirically I found that separating the <single> <single>/<single> <class>/<class> <single> definitions from the <class> <class> definitions by defining two lookups makes everything work fine.
By the way, DTL OTMaster can be used to debug kern-features files as it provides a detailed log file.
finally, I deleted everything and regrouped. I noticed, I had errors too.