FontLab 7 - Different kerning classes in masters

Igor Petrovic

I avoid posting software-specific questions on TD, but this is a particular case, sry

There is a one-axis (weight) font with two masters at axis extremes (Thin and Black), and the Black master is indicated as the main in the "Font Info". Kerning classes are different in these two masters.

Will kerning interpolate smoothly, or it's better to flat kerning in masters first (which increases the file size from ~80kb to ~100kb)?

James Puckett

Why do you have different classes in different masters?

Igor Petrovic

Long story short, it's the consequence of the process where two persons kerned the two masters independently

John Hudson

You can use the Match Kerning function in FL7. It will change the classes in all masters to match those of the active master, and will adjust the kerning pairs in each master to be corresponding, introducing zero value kern pairs as necessary.

Igor Petrovic

Thanks John. If I get it right the process is "lossless", in terms that even exceptions (or whatever else difference possibly) are retained. In other words, no single pair value is actually changed?

I am asking this because I remember that there were two types of "class actions" where "compress to classes" was described in the manual as "lossless" and the "extend classes" as "more aggressive" (meaning that you end up with somewhat different kerning after it). I know that Match Kerning is a different action, just wondering which logic it uses since there are not many details in the manual about it.

John Hudson

Yes, Match Kerning should be lossless. I recommend testing it in a copy of your font, and keeping the pre-matched source to go back to if you spot problems. I have only used Match Kerning in a situation where the classes in masters already matched, so was only affecting the pair lists. I’ve not tried it where both lists and classes differ, but the process it uses should be able to handle that situation.

I am asking this because I remember that there were two types of "class actions" where "compress to classes" was described in the manual as "lossless" and the "extend classes" as "more aggressive" (meaning that you end up with somewhat different kerning after it). 

I don’t consider either of those functions in FL7 truly ‘lossless’.

‘Extend Class Kerning’ is additive: it is useful if you have non-class kerning for some glyphs in a source and want to apply that kerning to currently un-kerned glyphs that you put into a class with the kerned ones. Typically it is something you would only do once, at the beginning of implementing class kerning, and not something you would use if you wanted to maintain backwards compatibility with existing kerning so as not to affect document reflow.

‘Compress to Class Kerning’ is sort of lossless, in that the resulting kerning will be compatible with the previously uncompressed kerning. What I don’t like about FL7’s implementation of this is that it also assumes you want to optimise the kerning data for size, which means that you end up with a lot of exceptions to class kerning being moved to single pairs, rather than retained as exception pairs (i.e. the ones that show up as red in the Kerning panel but still associated with the classes). What I don’t like about this is that it makes subsequent editing harder: I want to see exceptions as exceptions, so I can review them and determine if they should remain exceptions or might be reduced to the class kerning value. If these pairs get written as single pairs, it makes it much more difficult to identify them as exceptions.

I asked the FontLab developers to make a distinction between ‘Compressing to Class Kerning’—which should do just that—and ‘Optimising Class Kerning’, which should be a separate function and typically only something one would want done at the time the font is exported.

Igor Petrovic

Many thanks for the in-depth clarification. I agree, that would be a very useful distinction.

Also, a dialogue before executing these functions, in which one can limit the effect only to some classes/glyphs would be so much more comfortable. Kerning is a delicate and sometimes complicated system, it's not easy to comprehend and check the output of these functions on the whole set with exceptions and all

And of curiosity, what would happen if one keeps the classes unmatched? The kerning texts are set based on the current definitions/exceptions, which makes it easier for possible adjustments in the future.

John Hudson

And of curiosity, what would happen if one keeps the classes unmatched?

I’m not 100% sure. If you were only exporting instances that match the two masters, their kerning could be independent. But if you were exporting interpolation intermediate instances, then FontLab would have to perform matching of kerning, which it might do automatically in that case.

John Hudson

BTW, the FontLab forums are a pretty good place to ask this sort of question.

Igor Petrovic

Got it, thanks!