Kerning in OTF and InDesign

Ken Krugh's picture

Hello all, I'm new here and very happy to find you with thanks to Thomas Phinney for pointing the way. Most of my font creation experience is with Type 1 PC fonts, but I'll try and contribute all I can as I learn the OTF format.

I'm currently updating a Type 1 font we created a loooonnng time ago by opening the Type 1 files in FontLab 4 to create an OTF that we'll use in InDesign for Windows and pass off to a designer for InDesign on the Mac.

InDesign, however, isn't using the kern pairs in the OTF font. If I generate new PC Type 1 files from FontLab InDesign uses the kern pairs, but not in the OTF font. Other programs including Word 2003 are seeing the kern pairs.

I have a hunch it may be because InDesign is "smarter" with the OTF than the other programs, but I've not been able to find what it's looking at that is preventing the kerning.

Many thanks,
Ken

k.l.'s picture

Hello,

FL4 is not really a good choice any more and if possible, you should update to FLS5.
I assume you already have used the "update kern feature" button in the Kerning Assistance, so that a 'kern' feature shows up in the OpenType Panel.
However, you also need to add a substitution feature. This can be something as simple as

liga (
  sub aring by aring;
) liga;

It doesn't do anything visible, it's just for the sake that it's there. (Please exchange the parentheses in the code by braces. Of course this requires that there is an 'aring' glyph in the font.)

Ken Krugh's picture

Thanks VERY much K.L., I will update to the new FontLab.

It seems odd to me that I had to add the substitution as well. Is that a bug in FL4 or something with the OTF format.

Thanks again.

crossgrove's picture

In addition to this issue with the kern feature, you also need to be sure InDesign isn't using it's own kerning algorithm. Set kerning to "Metrics" rather than "Optical". Optical kerning in InDesign means the built-in kerning is being ignored, and the kerning engine of InDesign is adjusting things on the fly. The kerning (and general fit) of everything under Optical kerning also changes depending on the size you set your type, so for type designers doing fit and kerning testing, you should avoid InDesign's Optical kerning.

Miguel Sousa's picture

> Is that a bug in FL4 or something with the OTF format.

Neither. It was a bug (fixed in CS3) in CoolType, a library for enumerating and rendering fonts used by InDesign.

k.l.'s picture

K.K. -- Is that a bug in FL4 or something with the OTF format.
M.S. -- Neither.

Sorry if my "better update to FLS5" in this context suggested that it's an FL4 issue.

The fact that 'kern' feature is not recognized in InDesign is one thing, as Miguel said. (Good to hear this is fixed in the new version!)

The "update to FLS5" suggestion is unrelated to this.
Some things have been much refined in FLS5, like the way FL4 generates font names for OTFs, or the way FL4 generates the 'kern' feature. -- However, these are not serious issues if I correctly understand your description of your use of FontLab. E.g. it seems you don't use classes for kerning, and in this case the 'kern' feature which FL4 generates should be ok.
But then, the update is a real bargain ... (If you don't plan to include OT features in future, TypeTools 3 looks like a great tool too. Fewer options, thus less confusing than FLS5 may be at times. I just had a quick look into the demo yesterday.)

Karsten

Ken Krugh's picture

Thanks again to everyone, great info.

I've only used FL4 with any kind of regularity for a couple of weeks, but for what it's worth, I've already upgraded to 5 and would highly recommend anyone considering it to do so.

Ken

Miguel Sousa's picture

> The fact that ‘kern’ feature is not recognized in InDesign

What was happening was that GPOS data was being treated as a subset of GSUB data. So if no GSUB table was included in the font, the GPOS table would be ignored.
Interestingly, if the font was processed through VOLT, the bug wouldn't be triggered, because VOLT always creates a GSUB table, even if it ends up empty.

John Hudson's picture

If anyone is interested to know what such an empty VOLT-generated GSUB table looks like (Karsten was), here is how it looks in a TTX dump:

Harbs's picture

I have a question which is partially related to this discussion. I'm trying to kern a hebrew font in fontlab (I know how to do it in VOLT, but for my purposes, fontlab is easier). The tip on GSUBs helped the kerning take, but it only works properly on som pairs. With others, instead of kerning the correct letters, it kerns the one before the pair. I don't see any clear pattern. What could be causing this? Also, in VOLT, you can control the values of both letters in the pair, can the same be done in fontlab?

Syndicate content Syndicate content