'To' Kerning pair not kerning once exported and rendered

I’m busy kerning a large type family, and most of it seems to be working very well. However, the weirdest thing is happening – in the Light Italic font, the combination of ‘T’ and ‘o’ is not respecting the kerning set in the Glyphs interface. Stranger still, it appears upon looking at the Glyphs file in TextEdit that the kerning pair has indeed updated in the file.

I am doing this testing in Adobe Illustrator CC and InDesign CC, which could potentially be the problem … but all of my other kerning seems to be working perfectly in these applications. This includes the combinations of ‘T’ and ‘o’ I’ve kerning in the Roman set of this same typeface. The Bold end of the spectrum in this Italic type is also rendering correctly (there are 5 weights, created with multiple masters, so it’s as if the Light value just isn’t there) … so it seems to be a problem in the exporting.

Any idea how I might be able to solve this? Thanks for any pointers!

EDIT: I just tried to toggle on/off the lock of the kerning group, and sure enough … the bug is fixed. Weird. Any idea what happened?

When this reoccurs: can you send us the .glyphs file BEFORE you fix it? support (at) domain of this website

It seems that I have the same problem. Some kerning pairs don’t behave under Illustrator CS6, it is like there is no data for them. Seems a lot like the problem described above, but trying to toggle the lock on/off does not seem to fix the bug for me.

Are you sure you don’t have a font cache problem? https://www.glyphsapp.com/tutorials/testing-your-fonts-in-adobe-apps

I am using the Font Folder as an export destination, as shown in the link you shared. I didn’t install the font through Font Book.

Then we need the .glyphs and the .otf file to help.

I had a look at your files. The problem is that your cyrillic has a lot missing or bad kerning classes. That somehow throes of the kern feature generator so that it produces a not working kerning feature. I’ll have a look.

But fixing the classes and removing the exceptions is probably a good idea.

Could you explain “missing or bad kerning classes”. I just didn’t understand it.

There are a lot glyphs that are not in a class. e.g. De-cy is a component of the D but is not in the class, instead it has its own kerning values. And I didn’t understand why almost all glyphs are in the same right class but get it now, its all with an outstroke.

If I understand correctly, because De-cy has structural similarities with D it has to be in its class? And if I do not want it to be in a class with it, it would be a good practice to put it in a class of its own, so to speak? Otherwise it is automatically a bad kerning class or a missing one?

that shouldn’t be a problem but the current implementation has one with it.

The problem in this case is the cross script kerning that is not correctly separated.
You have kerning between Latin classes and the Cyrillic letters. So you could just as well put them all in one class or make sure there are no pairs between Latin and Cyrillic glyphs.

I’ll have a look at it and you file is a very good test case for that :wink:

Great :). It will be good if we can have that cross compatibility, without breaking the kerning on export. There are a lot of cases where it is very useful. I don’t think that this was a problem in the previous versions, but I could be wrong about that. Almost 1/3 of the letters are the same and it will be a pain in the a** to make the same kerning twice :smile:.

You don’t need to do the kerning twice, just put them in the Latin classes. I do that for all my font and never had a problem.

I do that too :). Your previous post threw me off a little. For example lets say I link latin “P” to cyrillic “P”, a lot of kerning is very similar for those two. If i understood correctly there will be a scenario where there will be a cross script kerning that is not correctly separated. From that i have one question. What is an example of incorrect separation?

As long as the cross script kerning is between classes, it is not a problem. Only if it is between a class and a single glyph that has no class.

Got it now :). Thank you for explaining.