I'm working on a font which is already largely kerned, using table-based kerning. The main problem, besides the inefficiency with regards to the storage of the kerning of accented glyphs (with which I am not hugely concerned) is that there are many accented glyphs which are not kerned like their base glyphs. This is an obvious use-case for class-based kerning. Right now, I have tried to redo the kerning manually in a class-based fashion in FontForge (this font is developed in FontForge). This, however, is tedious, and if possible, I'd like to avoid it. Is there any way to automatically convert a font's kerning from a table to class-based kerning? (I am willing to have it begin by naïvely putting /A and /Aacute in different classes, etc.; I'd just like to be able to import the pair-based kerning into a class-based kerning feature so I can edit it as classes in FontForge). I would strongly prefer a free and open-source solution for this problem if one exists, but I am happy to hear all suggestions. I've scoured the web for some guidance, but my Google-fu didn't provide me with any solid answers (though I did see some mentions of this problem). Anybody have any tips?
0
Comments
This is confusing to me. And, again, I am at a disadvantage because I am not familiar with how FontForge handles class kerning.
When you have /A in its own class and you have /Aring in its own class and you have kern pairs associated with both of these classes, and then you combine the two classes into a single class, then the kern pairs for the subsumed class need to be eliminated.
So, kerning data will need to change (even if the resulting computed kerning in the rendered font doesn’t change in value).
Or did you mean something else?