This happens every time I make a kern exception for glyphs with an attached ogonek. Often I have to make a kern exception for Aogonek followed by j. That is fine, however if I work on the kerning of another master in the file, I find on going back to the first master that the Aogonek j kern value is no longer an exception and the class A first to j has the value that was previously the exception value.
To get around this problem I now copy the kerning from each master and store it separately in a text file for when I export, when I paste the kerning back in to the kerning window, to make sure I am getting correct kerning.
Is this a bug or is there something I’m doing wrong?
I n your case you do not really need an exception but a pair between Aogonek and the j-class. To do that, type Aogonek+j, put the cursor before he Aogonek. Then click the lock next to the right kerning value. Then enter a kerning value. Check in the kerning panel, that it says Aogonek > @j. Do that in all masters. And never run “Compress kerning” after that.
@ mekkablue Thank you for the suggestion, will try the latest “cutting edge” version on a spare Mac.
@ GeorgSeifert Thank you but I don’t understand why this is not an exception. What about Aogonek against all the other glyphs that the A class would normally kern against? Also why does running “Compress Kerning” remove exceptions? Surely if this pair has a different value to the standard class based pair the value of the exception should be retained?
That is the job of compressing: compress exception kernings into group kernings. It only keeps exceptions for those glyphs where there already is group kerning with different values in place. If there’s no group kerning in place (likely for A-j), it will turn the first exception it finds into group kerning.
Yes, I understand that, but this is happening across masters. Would it be possible to have a “lock” on the kerning table of each master to ensure that changes do not happen when addressing kerning on another master?