I’ve had a problem with the class kerning, that I tried to wrap my head around for days now. I’ve been checking trough kerning and again and again I found weird pairs, that I thought, I’d deleted before. Then, a save or two later, the kering, miraculously was there again!
Example:
I kerned @F@i which contains a number of accented variations.
then made the exceptions for itilde, ibreve, imacron, etc. because the would touch the F
then, when i compressed the kering, some exeptions got lost and the group @i all for sudden went from -10 to 40
then I deleted that @i, compressed again and @i was there again with value 20
Also, on a similar note, sometimes, when I select for example >@E>@i in the kerning window, it would show >@V>@i in the edit view and I wouldn’t be able to delete >@E>@i without first deleting the >@V>@i
I think the main problem is that you should not compress the kerning at this stage of the production. It should only be used if you import a font and it has to much glyph kerning or if you had only glyph kerning and then you added classes.
OK, I see now, what it does and why it behaves this way. So technically a unlocked pair is the same a random pair with no class, hence glyphs does not differentiate. In my conception there were three types of kerning:
class based
class based, but unlocked form class
non class based
But, in fact, there’s only two types of kerning:
class based
non class based (inkl. all unlocked pairs)
And that’s where I see a problem is conception. Especially as long as the lock is not always in the spacing dialogue in the edit view. Although, this doesn’t really resolve the problem…
As I said, compressing is only a very rough first step to clean up some kerning data. If you case you should not use but close locks manually if you need too.
I just had the same problem as described here, and to be honest I think that simply saying one should not use ‘compress’ a this stage is a little too easy.
Firstly, the Glyphsapp tutorial on kerning describes ‘compress’ as:
Compress removes unnecessary kerning exceptions, e.g. the group kerning between the A group and the V group is –80, but you also have an individual ‘ÄV’ kerning pair of –80. Since that kerning exception makes no visible difference, the Compress function deems it unnecessary and will remove it.
In such a case, the kerning exception is obviously unnecessary, and it makes sense that it is dissolved. When reading that description, it seems like compress is safe to use at any point of the font production. If it isn’t, it would be nice if the tutorial could be changed to reflect that and/or Glyphs displays a warning when a user tries to compress.
Secondly, I don’t see why ‘compress’ behaves like this in the first place. (I’ve made a short screen recording that shows the behavior, in case you’re interested.) Compress could be a very useful function if it actually functioned as advertised. That means it only gets rid of the exception if there is no difference between the exception and the class. Now it is only giving me headaches.
Then the Tutorial is not correct. The Compress function looks for pairs between glyphs that have groups assigned. Then it checks if there is a class pair already (that means that the glyph pair is a true exertion). If it finds no class pair, it makes one. This is equivalent of closing the locks on that pair.
“Clean up” looks for class pairs that don’t have any glyphs assigned.