Lucia,

I agree -- this is simply a horrible and stupid limitation of OpenType. I really would like to know the person's name who developed the part of the OpenType specification that limited the size of a GPOS subtable to 64KB.

I believe Thomas Phinney should have a solution on that problem. I hope he sees that and replies.

Regards,
Adam

I think that yes, you need one or more subtable breaks. I know how to do them in the FDK, but I'm not sure how to do them in FontLab. Unfortunately, for the next week or more, I'm going to be busy finishing up some presentations and then travelling, so I don't have time to dig into this properly.

T

As far as I know, all you need to do is insert "subtable;" every once in a while. One of these every 100 lines or so should do it. This just helps break up the kern feature. I agree with Adam, this is a pretty pointless limitation, but fortunately there is an easy workaround.

So your kern feature might look like this:

pos T a -50;
pos T c -55;
subtable;
pos T e -55;

... etc. Don't forget that semicolon at the end of each line.

Alan

Aha!
I've wondered about this myself. Very helpful.

On a related note, has anyone ever noticed that while previewing
class based kerning in the OT preview window, FontLab will
apply a small amount of kerning to a glyph within a class even
if kerning has not been defined for the glyph? For instance,
the "ta" pair within the OT preview window will appear to have
kerning even though I haven't applied kerning to "ta". I have
however defined a kerning class for "a" and related accents.
If i generate the font and check it in InDesign the kerning
for the phantom pair of "ta" doesn't appear. This appears
to happen with any of my kerning classes within the OT
preview window. Hope this makes sense.

I've noticed other mistakes in the FontLab opentype kern feature preview. It comes up when I'm using opentype classes. If this is my 'kern' feature...

feature kern {
pos [B] @_kernO2 16;
pos [A] @_kernO2 -12;
pos @_kernO1 @_kernI2 -12;
} kern;

and this are my classes...

@_kernI2 = [B D E F H I K L P R];
@_kernO1 = [D O Q];
@_kernO2 = [C G O Q];

I'd expect the space between A and C to get smaller but instead it gets larger when I activate the 'kern' feature in the opentype preview. The kern occurs correctly in illustrator though, which is terribly frustrating because taking a round-trip to illustrator to check my class based kerning is not acceptable, but this seems to be the only way to check if I've coded my kern feature correctly.

Thanks a lot to everyone. (to spent yours weekends giving us interesting answers...)
I thought this was a silly question, but now I have the confirmation that it is a real problem!

Alan, I have done exactly this way, trying also to separate data with a certain "logic"... But it doesn't work.
And I have noticed the same problems with classes...

Thomas, when you will be back again, I would be gratefull if you could explain more. How Adobe fonts manage to have this feature? By the way I have opened the Minion Pro (with both greek and cyrillic) and if I compile the OT features I get the same error message. Does this font behave correctly with the apllications?

Best regards,
Lucia

Say for instance I don't recieve the error message Lucia describes.
Will the font still work if don't insert "subtable;"?

I have a full featured OT font with 2200 standard kerning
pairs and several kerning classes for use under the "kern" feature.

The font seems to be working fine in InDesign.
Is there a risk here?

Thanks

are there any ill effects of adding subtables to the kern feature? I was trying to follow along with the discussion on the OpenType mailing list a couple weeks back and got lost. can anyone explain this concisely?

Very short: (a) If some of your kern classes have overlapping content, FLS5 automatically inserts subtable breaks but will warn you that some pairs may never be accessed. (b) If you insert "subtable" manually to cope with too many kerning pairs and if the order of kerning pairs isn't right, then some kerning pairs may not make it into the font -- and you don't even get a warning.
The most complete description is in Adobe's Feature File Syntax document.

thanks for the explanation and the link, karsten. so my next question is what is the best workaround to avoid this problem? is it to not have overlapping content in kerning classes?

Yes, at best you create separate classes for first-glyphs-of-a-pair and for second-glyphs-of-a-pair -- even if they would contain the same glyphs:
_z.1: z' zdotaccent
_z.2: z' zdotaccent
Whatever suffices you actually choose to indicate that a class is intended to be first or second of a kerning pair, I'd precede it by underscore or better by period. This makes it easier to spot suffices and maybe to search/replace them. Just in case.
_z.1 then will be marked as leftside pair, _z.2 as rightside pair either in FLS5's Classes panel or Kerning Assistance panel.

This however addresses only overlapping of kerning classes' content (a), but not excessive kerning (b) ...

I plan to talk about this at length during ATypI's TypeTech forum.
Here's what I plan to cover:
— How to optimize the kern feature
— How to solve 'overflow' errors
— Making correct use of the 'subtable' command
— Kerning fonts with large_glyphsets/multiple_scripts

If you can hold until then, I believe it's going to be worth it.

I would give some hints now, but this issue can't really be handled in a couple of posts. Sorry :(

Looking at Alan's post above, I just noticed that his example will generate a 'bug'. A font with his code will compile, but the last pair (pos T e -55;) won't be accessible (and FontLab or the FDK won't warn you about this).

The thing is, all pairs that start with the same LEFT class, must be all contained within the same subtable.

I plan to talk about this at length during ATypI’s TypeTech forum.

This is good news!

This kern feature is driving me nuts. Beta ware man.. Isn't computers suppose to help REDUCE the workload and not make more ?

Ok my problem, I made a huge font and it's not even close to done. I compiles no errors. I added class Kerning. If I save it as a font I get a billion kerning gpos errors. Well actually only one cause one is all you need to break the font.

I'm not even finished the kerning. I have about 67 kerning classes. I searched the kern feature and these subtable; are there. I still get the error.

I saved it flat just out of curiosity. It's about 60,000 kern pairs stored that way. It takes ten minuets to load the font. Not the way to make it work.. I need the class kerning to work..

How do I get rid of the gpos error ? This would be FL.. The new one.

I answered my own question. I'll be nice and put the solution here for anyone that is looking for it.. I wish it would have just explained in the book but it does not..

How did I get there? I added unusual pairs in the Greek and the Russian language probably and kerned them. Big mistake probably cause later I accidentally added several of those to kerning classes. There is no tools to find the errors so it's welcome to hell..

Ok I exported the kerning data and deleted everything that looked odd. Single pair kerns keeping the classed based intact. Next I imported it and flattened the table then re-compressed it. Eureka ! I managed to save 576,536 pairs. Not bad, I lost about 20,000 or so. Better than losing it all by far.. I managed to save 4280 classed based pairs.

I tried a million different ideas and this was the only thing that worked.. The idea to avoid this kind of thing is color all the glyphs in a class and don't drag and drop those if there colored.

Live a learn.

Very extensive discussion: http://typophile.com/node/16413
Other discussion in random order, some more, some less useful ...
1 http://www.typophile.com/node/37959
2 http://www.typophile.com/node/37295
3 http://www.typophile.com/node/39456
4 http://www.typophile.com/node/20550
5 http://www.typophile.com/node/34558
6 http://www.typophile.com/node/29125 (added a remark)

tracking

ChrisL

I'm not getting some of those errors. I sub kerned some classes and I'm not getting some glyph pairs may never be accessed errors. Good thing too cause there is lots of them.

How I got into this boat without a paddle was Since I don't speak or write Russian or Greek I found books and kerned it that way.. Later I accidentally added some of those glyphs to classes. Don't do that cause that is a miserable error to recover from.

My entire font is now class based only. It's working perfectly so far. It's up to 646,782 stored flat pairs but amazingly there is only a little over 2000 (2335) tables so far.

Actually that is not the solution. Somehow FontLab 5.0.4 is generating that error all by itself.. I fixed it, now I'm right back in the same boat. I'm only kerning class based stuff now. I just tried it and I got that stupid error again. There is absolutely no pairs that are not defined in a class now.I never added glyphs to classes. I haven't kerned anything that is not in a class.

Like what the hell does this mean ? 0x19022

Think they could be a little more specific ? Like highlight where the error is or the pair it's located in.

I never added any subtables. If there is a error now the program all by itself, generated it.

I don't know what is causing the error to avoid it. What am I suppose to do try to compile it after every kern?

Ok figured it out eventually. I'll put the solution here.

The deal and how I got there. Too many sub tables cause I did the kerning not in the correct order. Do the classes then the sub classes then the singles. Don't mix and match.

That was problem Number 2. Reading Adobe's site it alludes to the fact that more than 6 subtables is a point of diminished returns. It does not say it will not compile. More than 6 you will get GPOS errors. Doing things not in the correct order maybe needlessly be generating subtables when they may in fact not be necessary. Why I got there was when I was using the font and noticed a kerning error I just fixed it so it would not go unrepaired. I thought I may never find it again or forget it ever existed. Avoid that habit at all costs. Write it down and just kern the classes. Check later and see if it is still there and fix it then only.

Problem Number 1.. Too many class kerns. I experimented to find out what is the max possible and still get it to compile. 15,000 is the magic number. Could be slightly higher but it will not compile 16,000. I had over 32,000..

What to do, what to do.... Gave up, started again. I readjusted the matrics to eliminate as many pairs as possible then re-kerned the font. I ended up with many more kern classes but fewer overall kerned pairs when I was done, less than 15,000 now. It compiles, not a single error. This is a hand kerned font. There is no auto kern with this one. That was a lot of work to toss away.

It's actually not a Fontlab problem, but there is a lack of understanding of it so there is a lack of documentation on it. Fontlab uses Adobe's system to compile the font. The error is being generated by the Adobe part.

I asked Fontlab and there answer was we don't also get why that error comes up.

There is one more thing I didn't get. I figure who cares so you got more than 32,000 class kerns just set it to only export so many pairs.. Nope, if you have that many pairs in the source it will not compile don't matter if you set it to export only two single pairs. You have to have 15,000 or less before that other part of the program even kicks in.

I'm pretty sure if you kern the font in the correct order you will only have two subtables. Single pair kerning then a subtable for sub class kerning then a subtable for class kerning in that order.

And now you know.