InDesign Shows Kern Value but doesn't Apply it Unless the Language is the Same

[ken_7703]

This is really a font issues of some sort, but I'm wondering if anyone has seen this behavior in InDesign to help me get closer to finding a solution.

We're updating a font we created to the newest version of the font editing software. When generating the OTF file from the newest version of editing software every thing almost perfect, except that InDesign isn't applying kern pairs between two characters that have different languages. The oddest thing is that when you click between the two characters InDesign shows the correct kern value in the button bar 😐 it just doesn't visually apply it. This does not happen with the font generated from the older version of the font editing software.

Has anyone else seen this behavior in InDedsign? Where it shows a kern value between to characters but doesn't actually implement it?

Thanks for reading!
Ken

[Mike Witherell]

Ken,

Have you tried setting the paragraph style to optical kerning instead of metrics kerning? One superiority of Optical Kerning is that it can work with differing type sizes and typefaces in the same line.

[ken_7703]

Thanks for responding. We're trying to maintain a level of backward compatibilty, so I'm trying to get it work like it has been working for past 12 years or so.

[Peter Kahrel]

Maybe ask the developers of your font editor what has changed.

[ken_7703]

Thanks Peter. I have a ticket going with them already. Their initial response was "Haven't seen that before." xD Doesn't bode well.

Something interesting (though maybe irrelevant) is that MS Word 365 has this same behavior with the OLD font as well as the new font. The language has to be the same for the kern pairs to get applied.

Oy.

[Peter Kahrel]

Strange behaviour. Is it just with language codes or also other codes that do (or should) not interfere with kerning? Discretionary hyphen, discretionary line break, text anchor, index marker, etc?

Which font editor is that, by the way? And what do you mean by xD?

[ken_7703]

I'm not sure about the other things, I've not tested those. I may have time to check those things our later this afternoon.

Going from FontLab 5 to FontLab 8.

Yeah, sorry, that's an old texting thing, before emojis. It's supposed to be laughing hard enough to squint.

[ken_7703]

According to FontLab: "Studio 5 and FL 8 just use different versions of the OpenType font compiler: AFDKO." One of the differences is that FL8 includes a Glyph Definition table (GDEF) that FL5 did NOT. They did a good experiment for me; in the font generated from FL8, they reduced the GDEF table in the OTF to just a space, essentially removing it, and the kerning started working again across languages like the FL5 fonts. BUT, the kerning wasn't exactly the same as the FL5 font.

So InDesign is using the GDEF table, possibly indirectly, in some way when determining kerning.

Also, you called it, Peter. Unfortunately it is also happening across different kinds of formatting, as show in the superscript example below. FL8 font is on the left (InD shows a value but doesn't implement it), FL5 font is on the right, InD implements is no matter the formatting.

I'm not coming up with any good way to make this backward compatible that doesn't make generating and managing the font more complicated than it should be. Only thing I can do is use the latest and greatest going forward and live with the consequences when we have to go back to the older InD files, or load the FL5 fonts if / when we need to go back.

Yowza.

[Dirk Becker]

Fonts can have details (trying to avoid the term "feature") that are specific to language or writing script. So it makes sense to break composition at language changes, which would ignore the kerning pair. On the other hand when the font has no such language specific details it makes sense to run thru … Interesting that there apparently is such an optimization.

Is there any such language specific detail in your font?

What particular languages are involved?

For example, are these the same glyphs across the documents? I know that would rather be GSUB…

Could be that they use the presence of the GDEF as one trigger rather than descending into it to watch out for relevant languages.

What particular composer? InDesign is using HarfBuzz for shaping – I don't know whether for all of the composers, how the internal decisions are made, and whether that is relevant at all. Would be interesting to watch …

Can you share copies of both fonts for testing, e.g. stripped down to the relevant glyphs if it is a commercial font, and different font name so we can have them in the same document without effort? I use my own limited composer for preview of OpenType features in a plug-in, and would love to mimic the exact behaviour. When I initially wrote it ten years ago I found only one example (Arial Hebrew limitations for the slashed zero feature) but don't even remember what I did with it. I'd also like to have a look at that GDEF.

Have you repeated your tests in e.g. Illustrator?

I'd suggest to also cross-post in Type and Typography / mention this thread – and please keep us informed.

[ken_7703]

Yowza Dirk, that's a log of info! Thanks for responding.

I'm moving forward with just using the font generated form FL8 and will deal with going back into older InD files. If I have some time over the next few days I'll see what I can do, though I'm very hesitant to send the font anywhere as, technically, it does not belong to us and is propriatary to a series.

I'll post back when I have some time.

Thanks again!

[Dirk Becker]

When I reread your message on a larger screen and later in the day, I noticed that reduced GDEF experiment. Could be that previously the GDEF had some language specific detail in it, I think GDEF has provisions for that. Still only with my private theory that when nothing language specific is in the font the text runs might extend across languages. Could be anything else.

There are plenty more open questions, e.g. is the superscript a dedicated glyph (allowing for different kerning)? Difficult to tell, maybe you can see the glyph id thru the glyphs panel.

I understand those limitations of commercial and especially custom fonts, so too bad we can't have a deeper look at it. I'm anyway in no position to do much about it even if we know more.

Anyway thanks for bringing up the interesting topic.