TTF Kerning

Ken Krugh's picture

A client with a TrueType font wanted some glyphs added but were not able to contact the person who created it the font initially.

Because it uses has at least MKMK, which FontLab doesn't support, I used ttx to create a text file and through a combination of FontLab and the ttx file was able to add the glyphs they wanted.

They now want some kerning added, which I did in the ttx text file and recompiled. The new kerning works when the font is used in Word 2003 but NOT in Word 2010 or InDesign. There is SOME sort of kerning working in InDesign as I can see that the characters pairs listed in the font have kerning between them. Likewise for Word 2010, turning the kerning on and off with some text selected makes definite changes at some kerning pairs.

The font does have a DSIG feature (for that weird Word problem).

Any ideas?

Many thanks,
Ken

Ken Krugh's picture

Just realized that InDesign is showing a different kerning value than what is in the "kern" table of the ttx. For instance, the kern table shows <pair l="T" r="o" v="-143"/> but InDesign's kern menu shows -70.

So InDesign is definitely looking at something else in the font and using it as kerning. I'm assuming Word 2010 is using that same thing as kerning.

Thanks again for any help anyone can offer.

John Hudson's picture

InDesign will be using the OpenType GPOS {kern} feature kerning, rather than what might be in the 'kern' table. Generally speaking, it is not advisable for a font to contain both kinds of kerning, but some fonts include a 'kern' table for backwards compatibility with e.g. older versions of MS Office. The GPOS kerning can include class kerning and even contextual kerning; the 'kern' table is quite limited and due to application issues it is generally recommended to include no more than c.6000 pairs in the 'kern' table. This means that when fonts do contain both kinds of kerning, the 'kern' table will usually include only a subset of the GPOS kerning. A good workflow will ensure that this subset will at least use the same values as the GPOS kerning, but I have seen fonts such as you describe, in which the two differ. This might happen if, for example, GPOS kerning developed for OpenType versions of a font involved significant new development and revision, but the 'kern' table was copied from an older version, which might be done on purpose to avoid existing document reflow in older apps.

blokland's picture

Ken: ‘Because it uses has at least MKMK, which FontLab doesn't support, I used ttx to create a text file and through a combination of FontLab […]

An alternative, and perhaps a somewhat more simple, route is to add the glyphs directly to the font in OTM, and to use the GUI for the mark (to mark) positioning.

FEB

Ken Krugh's picture

Yeah, I looked briefly at the GPOS but couldn't see much by way of readily readable "code" that I could decipher and match up with the values InDesign shows.

Now that I read your post, John, I remember having the reverse problem where the class kerning I'd added to a set of fonts we upgraded wasn't working in Word (2003 at the time) but with the kerning table still there it was using that.

It might be for this particular project that I can simply remove the GPOS completely as they've only used the font, thus far, in Word 2003. All of this new work on the font is in preparation for upgrading.

I'll give OTM a look, FEB.

Thanks very much for taking the time to reply guys.

blokland's picture

Ken: ‘I'll give OTM a look, FEB.

If you send me (FEB[at]dutchtypelibrary.com) your e-mail address and let me know which OS you use, then I will send you a download link for the full version of OTM 2.4, so that you can test it.

Frank

Jens Kutilek's picture

Just realized that InDesign is showing a different kerning value than what is in the "kern" table of the ttx. For instance, the kern table shows but InDesign's kern menu shows -70.

I don’t think the kerning values actually differ. InDesign displays kerning values in ‰ of 1 em, while in a font the kerning values are relative to the units per em setting, in this case probably 2048.

70/1000 = 143/2048

Ken Krugh's picture

Thanks Jens, you're correct, I didn't think to check the UPM, though I should have.

Thanks again to all for the help. Unfortunately, I do this font stuff as an aside to many other things. Maybe someday I'll have time to really get (and keep) a grasp on it.

All the Best,
Ken

Syndicate content Syndicate content