Applying a kerning group without producing an exception automatically

I have a kerning table overflow. So maybe too many groupless glyphs.
Now I try to add groups to actually groupless glyphs (eg. “seven” ). At least this helped in FL5.

But when I add a group to glyph, that has already a kerning pair, Glyphs opens the kerning lock and produces an exception, which is completely senseless and unwanted in this case.

Also the mekkablue script “Add Kerning Groups” does.

Is it possible to prevent this behaviour?

Adding groups would not help by itself. Only if you have a lot kerning between glyphs and classes.

After you added the groups, you need to do “Compress Kerning” in the Kerning Panel. This will copy all kerning from glyphs to groups if possible.

In FL5 it does. Because the table size of “groupless” glyphs will be reduced…

Yes. Works fine.

But why is Glyphs always opening the lock? Even if there are no other kerning pairs. And even if there are no other glyphs in the class.

But the system of kerning classes in FLS is broken. The table sizes depends on a few other things. Mostly on the number of classes and how many glyph to group kerning do you have.

The open lock means that the kerning is to a single glyph what has a group. You can see the difference in the kerning panel. There you see kerning to groups with the @ and kerning to the plain glyph names. This is how the kern feature in OpenType works. There you can only have kerning between single glyphs or between two classes. The Editors usually allow kerning between groups and single glyphs. But they will be flattened on export. So a kerning between T and @A will produce 10–25 pairs. But @T+@A only one (class kerning is a bit more complicated …).

Lets assume, we have a font without any kerning and without classes.
Now I kern the “o” unter the “T”.
The lock remains closed. So far so good.

Now I enter a classname to the “o”, because I want to share the kerning with “odieresis”, that didn’t exist before. (Yes, in a perfect world, I should add classes before kerning, but… you know…)

On pressing enter, Glyphs opens the lock.
So I have to manually close them for all masters, although this is not an exception.
Why does the lock not stay closed?

because you decided to have kerning between the T and the o. Even if it makes sense to put o and odieresis in one group, you might need an exception because the T+ö might need different kerning. So Glyphs can’t just move kerning form glyphs to classes.

In FLS 5, the classes where more of an afterthought. So the class would just follow the kerning if the “key” glyph. That would make it impossible to have an exception for T+o.

I see.
So it would not be possible to simply script the lock. Instead a reorganization of the kerning has to be performed. Is that right?

All locks can be set automatically. What do you mean by ‘reorganize’?

I thought I understood. But it seems, that I have not :frowning:

Ok, once again.

  1. I set a kerning between T and “someglyph”. No Groups, because I have only this “someglyph” with this special shape in my font. Result in Glyphs’ metrics: T;o;-75 . So far, so good.

Sometimes later, kerning is al done, I decide to have another script, e.g. cyrillic with some other glyphs with the same shape like the “someglyph”.


  1. I set a group name for “someglyph”. Result in Glyphs: The lock changes to “unock” and the metrics are : @MMK_R_someglyph;“someglyph” and T;someglyph;-75, so in fact the kerning pair is now an exception.

But as “someglyph” is my “group-leader”, I have to iterate through all masters and all new glyphs and pull the lock back to “closed”.

So the question is, can I change this behavior somehow? Is it possible, that the lock remains locked on entering a class name?

There is no class leader. All members of a class are equal.

Just alway add groups to all glyphs before you start kerning (even to tho that you don’t intend to kern). There are script that can help with that.

If you need to add a group after you added the kerning, you can use the compress kerning in the kerning panel.