It looks like you're new here. If you want to get involved, click one of these buttons!
Technique and Theory
Type Design Critiques
Type Design Software
Lettering and Calligraphy
Technique and Theory
History of Typography
Suggestions and Bug Reports
Kern feature in FL VI
It seems FL VI writes much longer kern feature code than FL 5 did.
It seems to include both class based and flat kerning. Can anyone shed light on this?
edited August 2
When you say "longer kern feature code," do you mean the plain-text representation as FEA code, or the compiled font?
The plain-text FEA code is not at all the same thing....
I mean what is generated when pressing "build kern feature", which I guess equals to plain-text FEA..
edited August 3
FontLab VI uses KLTF kerning optimization (licensed from Karsten Lücke). The
of the kerning, that you see as plain text is
, but the
compiled font should be smaller
Class kerning that would cause kern table overflows if generated in a font from FontLab Studio 5, usually compiles and works when generated from VI, thanks to being significantly smaller in the final font.
Class kerning in a compiled font is essentially a two-dimensional array. The plain-text FEA code representation is essentially linear. If you double the number of classes on both left and right sides, you make the plain text representation
as long, but the compiled version is
Subtable breaks can make the compiled font smaller, however. Imagine a tic-tac-toe board with X's along a diagonal. Without subtable breaks, the font would need all nine squares worth of data. But breaking it into three subtables, for example only kerning Latin against Latin, Greek against Greek, and Cyrillic against Cyrillic, and then breaking the kerning into three separate subtables, makes for a smaller compiled font—the kerning data uses 1/3 the space.
KLTF optimization can make intelligent use of subtables as well as dropping things from class kerning into flat kerning, when doing so requires less data in the final font.
So, it is complicated, and there is not a one-to-one relationship between any plain-text representation of kerning that includes class kerning, and the actual font data in the output font.
Got it, thanks for explaining!
Forum Software Powered by Vanilla