Unpredictable exceptions

[rohh]

Hello,

I have a very strange behavior, where the kerning result of kern-on gives me tons of unpredictable and illogical exceptions. I do it with my kerning groups and the file size of 36kb. Tried 44kb no difference regarding the issue.

When working with kern-on everything looks perfect, I am adjusting the details to a very satisfying result, but later after compiling I get tons of strange kerning exceptions on a simple pairs, like n-o for example. Sometimes it results in very big gaps or letters colliding. When I click the lock to lock the pair again it looks fine, but the quantity of such problematic pairs is just huge.

Edit:
It seems it must have been some error during the compiling process - I do not know why this happened multiple times, but I now I managed to export it with much better result. Still, I find some strange exception but they are not so many of them as previously.

[SCarewe]

Did you define pairs like n–o as a model in Kern On? Kern On will leave these pairs as exceptions for compatibility reasons.

[Tim Ahrens]

Sorry you are not getting the results you expect. It’s a bit difficult to tell what is going on without seeing it myself.

Would you mind sending me the .glyphs file? Then I can have a closer look. It is not unthinkable that there is a small slip somewhere in the code that causes wrong output in your case.

[brianbrubaker]

SCarewe wrote:
> Did you define pairs like n–o as a model in Kern On? Kern On will leave
> these pairs as exceptions for compatibility reasons.

Okay, I've actually been wondering about this. In the "old way" of kerning, the the n–o kerning relationship would be locked. But what you're saying is that KO keeps models as unlocked / exceptions? Could you help me understand why? Simply because of what I'm used to, it's been a little jarring to see these really important kerning pairs unlocked. I've always left it alone because I want to trust KO where I can, but knowing why would really give me some peace of mind.

[Tim Ahrens]

I suppose you refer to the little lock symbol in Glyphs next to the kerning value? It’s just how Glyphs shows you whether a pair is a class-class pair (locked icon) or a glyph-glyph pair, a.k.a. exception (unlocked icon). It’s a strange visualisation as class-class pairs are not protected (“locked”) in any way. In Glyphs’ Kerning Window, you can see that some pairs have bold blue partners that start with an @ (class-class pairs), or green-brownish pairs that show the glyph names (glyph-glyph pairs a.k.a exceptions). To me, that’s clearer than the lock symbol.

When Kern On generates the full final kerning, it generates class kerning and glyph-glyph kerning. This whole process is somewhat lossy, however: in order to restrict the kerning to the given kB size, not all required glyph-glyph pairs are written.

In order to guarantee that the values of the model pairs do not change when Kern On is finalizing the kerning and then re-started, they are always written as glyph-glyph pairs. Keep in mind that superfluous glyph-glyph pairs will automatically be omitted when Glyphs generates the fonts.

(As a side note, Glyphs allows to create glyph-class pairs but these are expanded to glyph-glyph pairs when Glyphs generates the font, as this concept does not exist in OTF/TTF. This is why Kern On does not generate glyph-class pairs in the first place.)

[brianbrubaker]

As is usual, this is very helpful, Tim—exactly the info I was looking for. Thanks so much, man!