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.

Some years and tests later: Said "tidying up" does not make a difference.

[Not meant to revive old threads. I just want to withdraw a former false claim.]

What is "flat kerning"? Is it the same thing as plain kerning?

I am just now learning about the Glyph Positioning table (GPOS based kerning). All I know about it is that it's a table that microsoft will read to interpret the kerning values for my opentype-flavored opentype font. I know that in fontlab I can export it if I have the box checked next to "Generate "kern" feature if it is not defined" under the opentype export in the preferences, along with "export opentype tables", but where can I edit the GPOS kerning feature/table?

Mr. Sousa - What is code optimization (for kerning)? How do you do it? Do you use the opentype panel and change the code in it? If so, why do that instead of use the metrics window, as I have been doing for all of my kerning adjustments? All you need to do is to click the button "Apply and Save" in Kerning Assistance to make adjustments made in the metrics window show up in the opentype panel, -- even if you have defined no classes at all, this will generate a "kern" feature, I believe. Or am I wrong about this? I'm getting confused about some of these things!

BTW I am working on OTF-flavored OpenType fonts.

> What is "flat kerning"? Is it the same thing as plain kerning?

Yes.

You can edit the "kern" feature in the OpenType panel. You can explicitly convert your class-based FontLab kerning into the "kern" feature in the OpenType panel flyout menu, "Generate kern feature". If you don't do that and the option "Generate "kern" feature if it is not defined" is enabled, then FLS will generate the "kern" feature when generating the font.

But if you do it explicitly in the OpenType panel, you'll see exactly what goes into the font.

A.

Thanks twardoch! I'll use this Opentype Panel method from now on.

I'm doing it right now and it's asking me if I want to rebuild it. I'm clicking yes. This is cool. I've never done it this way before.

twardoch I love you!

That totally worked.

Today I upgraded from fontlab 4.5 to 5, but I hadn't really done any more testing to my font yet. Then I did what you said. "...edit the "kern" feature in the OpenType panel. You can explicitly convert your class-based FontLab kerning into the "kern" feature in the OpenType panel flyout menu, "Generate kern feature". If you don't do that and the option "Generate "kern" feature if it is not defined" is enabled, then FLS will generate the "kern" feature when generating the font." It asked me if I wanted to rebuild it, and I clicked yes. That fixed all my kerning problems. It looks perfect in textedit now. I haven't tested it in Word yet but my version of word is old anyway and may not be opentype savvy. But hopefully that's fine too. I'll report back on that soon.

I'm very excited as I am now almost finished with this font!

THANX AGAIN TWARDOCH!

Hello Mr Twardoch,

I am wondering, is there a way to create a class-based kerning table from a group of kerning pairs. Reason I ask is I have an AFM file that contains 6k kern pairs that I would like to convert.

Thanks
Pete