GPOS based kerning can handle pairs and classes equally well. Kerning in the 'kern' table can only do pairs (ignoring Apple's extensions for AAT for the moment).

Most Adobe fonts have both pairs and class-based kerning in the GPOS table 'kern' feature. This works just fine.

If you are asking about having both GPOS kern feature and 'kern' table in the same font, that's another question. The results of doing so are undefined in the spec, and there's no guarantee what will happen. But a number of folks have done it, without obvious disasters occurring.

Regards,

T

i guess i should clarify my question a bit. is there any reason why one should duplicate what's handled by class-based kerning with pairs in the GPOS kern feature? maybe i'm overthinking this...

If I understood your question, the answer is "No". To include kerning data in OpenType CFF fonts all you need to do is to provide a 'kern' feature with all the positioning rules (and necessary classes, obviously). That's how it's done in Adobe's fonts.

thnx for your answer, Miguel. I was wondering, is it possible to get notes for your Adventures in Class Kerning? I can follow the PDF untill i get to the code optimization portion, and then i get lost.

I don't have any notes, unfortunately. I demoed a macro with a few fonts, and that's where the code comes from. Yes, the slides are not very useful by themselves. Is there something specific you'd like to know?

Essentially, I demonstrated that in big fonts (2500+ glyphs, 3 scripts, 15000+ kerning pairs, for example) it is necessary to optimize the code of the 'kern' feature. FontLab 5.x does a great job, but unfortunately it's not enough. And in some situations, the order in which the kerning classes are arranged in the Classes panel (yes, the Classes panel), might mean the difference between one 'kern' feature that compiles, and one that doesn't.*

* this has to do with the fact that when FontLab generates the 'kern' feature, the class-class kern commands are ordered in the same way as the kerning classes appear on the Classes panel. And this order might not be the ideal if subtable breaks are also added.
In a font containing kerning classes for Latin, Greek, Cyrillic and punctuation, for example, one of the ways to avoid overflow errors upon trying to compile a 'kern' feature, is by arranging the same kind of classes next to each other (i.e. all Latin classes, then all Greek classes, and so on).

Also, in a big font project, FontLab generates a 'kern' feature with too many subtable breaks. In my example, FL was adding about 11 subtable breaks, when only 3 were effectively necessary, as I showed.

> Essentially, I demonstrated...

And I kept interrupting Miguel all the time ;> I must admit that Miguel’s talk was a very good summary of the topic even though in a few details he was not entirely correct. His talk inspired Sergey Malkin (who maintains Microsoft VOLT) and Yuri Yarmola (our chief Fontlab Ltd. programmer) to think about some automatic optimization of kerning so that the user will not have to worry so much about this. I hope that the guys will come to some conclusion!

A.

"I hope that the guys will come to some conclusion! "
And that it will soon be available in FontLab Stidio 5.03 :-P

"Ready when it is ready" :-)

ChrisL

Adam, here are some ideas, regarding kerning handling, for a future iteration of FontLab Studio:
-- Allow the creation of class supersets/class groups (classes that contain classes or classes+glyphs)
-- In "Class kerning with exceptions" mode, allow exceptions of key-glyph/key-glyph pairs, or abandon the concept of key-glyph (this might sound strange at first, but class kerning is about kerning classes and glyphs; the key-glyph is in a grey area, because it can act as glyph or as a class)
-- Compile kerning data on the fly, and report kerning problems (class overlapping, inaccessible kern pairs downstream, etc.)

This will keep you guys busy for a while... :^)

-- In "Class kerning with exceptions" mode, allow exceptions of key-glyph/key-glyph pairs, or abandon the concept of key-glyph (this might sound strange at first, but class kerning is about kerning classes and glyphs; the key-glyph is in a grey area, because it can act as glyph or as a class)

Oh yes!
But it seems this would require to think of kerning and the interface differently. (My assumption is that when FL started using class kerning, the key-glyph approach was a convenient way to remain compatible with the way kerning is handled in FL files.)

> Allow the creation of class supersets/class groups

I don’t think so. I cannot imagine how this could be represented in the user interface.

> In “Class kerning with exceptions” mode,
> allow exceptions of key-glyph/key-glyph pairs,
> or abandon the concept of key-glyph

Again, we could run into UI problems. But perhaps we can do something about it.

> Compile kerning data on the fly, and
> report kerning problems (class overlapping

I think that the kerning problem should be solved in a completely different manner. The final classes embedded in the font do not, conceptually, have anything in common with the classes used in the design process. The classes in an OpenType font are a mechanism for technical compression. The classes used in the design are for the designer. I hope that we can find a solution that will separate those two entirely: the designer will be free to set up classes in the FontLab Studio interface in any possible way (such as, mix Cyrillic A with Latin A in one class), but in the process of the actual kerning compilation, the kerning will be composed in a different, optimal way, including both pairpos pairs and class pairs depending on the outcome of an automatic optimization algorithm.

Unlike a handful of experts at Adobe, regular type designers do not have to, and should not be bothered with things like subtable breaks, class overlapping etc.

We will keep the UI access and the programmatic access to the OpenType Layout feature definition source code (in AFDKO syntax). This means that people are free to develop their own Python code to transform the "visual" kerning information (Classes panel and Metrics window) into the AFDKO code -- just the way you did it Miguel.

Best regards,
Adam

Stumbling across this old thread again ...
I did some quick experiments in this respect recently. To my surprise I found that though "tidying up" classes helps AFDKO a bit when generating a kern feature (replacing left class and right class that have same glyph coverage by a single class will create a more economic GPOS), it does not necessarily help to completely rearrange kerning and classes. So providing AFDKO with a kern feature as VOLT's kern2volt would create it rather troubles AFDKO. This maybe because AFDKO and VOLT generate GPOS differently, and AFDKO works better with a kern feature more or less following the designer's logic of setting up classes.