You should try to generate the kern feature via AFDKO, this might solve the problem!

http://typophile.com/node/37295
http://blogs.adobe.com/typblography/atypi2006/atypi_Adventures_in_class_...

Most likely, the problem resides in your own defined kerning classes. The likely culprit is a duplicate glyph in two or more of your classes.

We ran into this problem recently and found that the ae glyph was present in its own class (left and right position), and also present in a class e1 (e as the first or left glyph). Removing one of the instances solved the problem.

a duplicate glyph in two or more of your classes
Which should be quite easy to find via kerning assistance.

Thanks, for the answers.
But the classes are not the problem. FL itself doesn’t find a problem within the classes, i also checked all classes myself.
In case of this script font i would omit classes, because there are only very few glyphs looking similar on one or both sides. But even if i expand class kerning to plain pair kerning and delete all classes, the problem remains. This raises the question “are there any subtables in flat kerning?”
Does anyone know what FL’s output codes e.g. “subtable (0x1ce1e)” are meaning? Then it would be easy to find where the problem is, i think.

Hmmmm...

Are we certain that this error pertains to GPOS, and not to the ’kern’ table (and I do mean kern *table*, not subtable of GPOS)? This situation would make some sense if that is the case. There is a fundamental problem with the specification of the ’kern’ table, in that the length descriptor is a 16-bit unsigned integer (USHORT) with maximum capacity of 65536. But the number of pairs is also given as a USHORT, while the length of each entry is 6 bytes. So the length field will overflow whenever there are more than 10922 flat pairs (actually I think it is less than that because of some header info). Some tools, including FontLab, choke on this situation. But again, it is specifically with the ’kern’ table, not GPOS kerning. I think it is possible to toggle the use of a ’kern’ table when generating in FL, perhaps try playing with that and see if it makes any difference?

This is a pretty well-understood issue, and as Christoph pointed you towards in the first reply, you have too many classes within a single subtable, so you’re breaking the 64K limit on the size of a subtable.

I *think* FontLab supports the subtable break code from the AFDKO, in which case that’s what you need to do (with switching over to AFDKO being more of a last resort). Christopher Slye or Miguel Sousa from my team could advise more on the detailed tactics of how to do this, if one of them stops by soon. They’re both at TypeCon right now, but I expect they’ll be back online in a day or two.

T

Thanks a lot again for your answers.

My largest subtable at the moment contains the incredible number of over 8.000 lines. And i’m not yet finished with creating additional glyphs...
As i mentioned above, in this special font the number of classes is rather limited. And in most classes only two glyphs are contained, thus the number of subtables is very limited, too.

Thomas, i will try to get the newer AFDKO running... it seems to be the only promising way.

The newer AFDKO didn’t solve it.
Now i created new classes with as many glyps in each class as possibe, even with glyphs whose forms that doesn’t look similar at first sight. In this way i could reduce the number of kerning pairs down to 3.100 !!! Compressed to Class Kerning its only 1127 entries in the kern feature definition!!! Maybe i exaggerated it somewhat... but now there’s no subtable overflow any more :-)

But FL S’ output after compiling the OpenType features now shows the following:
[WARNING] Start of new pair positioning subtable; some pairs may never be accessed: [... ...] [... ...]

I think i can ignore that.

You can ignore that, but it means that there are classes which contain the same glyphs. It’s easy for you to check that.
Pieter

You’re right, i’m sorry. I just forgot to check the classes at least before compiling... ;-}

PvR — You can ignore that, but it means that there are classes which contain the same glyphs.

Sure about the “can ignore that” part? The warning says Start of new pair positioning subtable; some pairs may never be accessed, so you better not ignore it unless you don’t care if all your kerning pairs show up when using the font.  :D

Karsten

Hello Karsten,

Yes, you are right. I mean that the font will be generated and will work but some kerning pairs will not be there.
Thanks.

Pieter