I almost never make kerning exceptions, and I generally set my groups up early, but I’m constantly finding open lock icons that screw up my kerning. What am I doing to make this happen? Is there any way to relock these en masse, or at least search for them so I can lock them one by one? (Compressing, even multiple times, doesn’t do the trick.)
Thanks!
Closing all locks:
Window > Kerning, select all, choose Compress from the gear menu.
If they keep reappearing, even if you had closed them, please send the file.
I’m afraid I haven’t kept track of whether the same locks keep popping open; I’ll start keeping notes on this. What do I know is, I keep finding unlocked icons, and I know I’m not unlocking them on purpose. Is there some way I could be unlocking them accidentally? A keyboard shortcut I’m taking without meaning to?
Thanks.
This doesn’t close all the locks, I’m afraid.
Is there any way I can search for unlocked kern pairs?
It will not close locks when there is an exception that does not match the group kerning, i.e., if @V @A kerns -100, but @V Adieresis kerns -90. So perhaps you worked on the kerning after some locks got open, and accidentally added kerning exceptions?
I’ll bet I do sometimes accidentally work on kerning after locks pop open, Rainer. Thanks.
But this still doesn’t tell me how the locks get open. This has happened in every Glyphs file I’ve ever worked on.
And I’m sorry to keep harping on this, but is there any way to search for open locks/kerning exceptions? I don’t know how to fix this otherwise.
You can search for open locks in the kerning panel.
Thanks, Georg. Didn’t realize all the lightface items were exceptions. This works.
I see two different typestyles in the Kerning panel: Bold for groups and regular for single pairs between glyphs that aren’t in any groups. I know there are exceptions lurking around, because your instruction for closing all locks doesn’t close them all. But I don’t see any grayed entries in the Kerning panel. Is there any other way to find them? It might be nice if we could somehow identify and target such exceptions rather than just trust Glyphs to eradicate them, since it’s not doing that as I would like. What I really want is to be able to forcibly remove all exceptions to any group kerning value, which you say is not supposed to happen. Do we have different definitions for “kernng exception”? I want to keep individual pairs, pairs between a glyph and a group, pairs between a group and a glyph, and between a group and a group. I want to eliminate all exceptions to all of the group scenarios, which “compress” doesn’t do.
The gray entries in the list are kerning pairs between glyphs instead of kerning between classes. And open lock means that there is a kerning pair with a glyphs that actually has a class.
So there is no place to see which pairs are real exceptions except to go looking for locks? Because the “grayed” values contain both real exceptions and individual pairs between single glyphs not in groups. I don’t want to remove those single pairs because those are likely important pairs between odd-shaped glyphs that need individual attention.
My real question is much like the original one from Max_Phillips:
How can I remove all exceptions to all group pair values?
I would assign groups to all glyph (even if there is only one glyph per group) and then click the compress button. All grey pairs are exceptions then.
And you can filter for glyph kerning, click on one pairs after the other and check the look status. But that can be tedious.
I’ll see if I can make that easier.
I’m still a little confused about this. I would not expect to have to assign groups to every glyph. Unique shapes mean those glyphs don’t need groups. so why cause the extra work? If my character set is 450 glyphs with names like awaa-ethiopic, can you imagine the effort it would take? Metrics Machine is the only tool I know that can at least label a group automatically, but I still don’t see the purpose.
I think Rainer has contradicted your suggestion for compressing: He points out that the compress function only works on pairs with the same value as a group. So those should obviously be compressed, because they aren’t exceptions, they’re duplicates. Exceptions should be able to be made compliant with the group value or removed from the group, shouldn’t they?
Something about Glyphs is able to keep track of which pairs have a value that differs from the group value. So why can’t that intelligence just report which pairs those are, in a list or new tab, so I can address only those?
This goes back to my original idea about kerning: a shape either matches others and can be grouped with them (and kerned the same value), or it doesn’t, and it gets its own unique pair values. Not something in between. Am I missing something? What are exceptions actually for?
This became more urgent recently when a lot of conflicts were found in my OTF between group and exception pair values. Without me actively trying to create exceptions, some got in there anyway, and I had to walk through a lot of glyphs to find them and re-lock locks.
Compress only works for pairs that contain a glyph and there the corresponding classes don’t have kerning.
I explained why I suggest to add classes to all glyphs. There is a script in my scripts repository that can assign groups.
How does your script determine the groups?
There are some default groups and it looks at the components. For all other, it uses the name of the glyph itself (to make a single group).