RTL Kerning of punctuation/numerals in InDesign

Ori Ben-Dor

Hello,

I've encountered an issue with InDesign and I'm hoping to find a workaround at the font level.

I'm kerning a Hebrew font.

When I kern two Hebrew letters, it works fine in InDesign 2024 with RTL support.
However, when I kern a pair consisting of punctuation or numerals, it doesn't.

I've tried both RTL rules (e.g., pos period seven <-200 0 -200 0>) and LTR rules (e.g., pos period seven -200), but neither seems to work.

Sometimes I get weird results, for instance:



In the top line, the kerning rule for period-seven (remember, this is RTL text) is ignored, but in the bottom line, it takes effect. I don't understand why; it's as if the presence of other characters, including Hebrew letters, in the same line somehow interferes with the kerning of period-seven.

I'd appreciate any help with this.

Thanks!

John Hudson

The numeral characters have strong LTR directionality, so even though they are occurring within an overall RTL context, they are processed as LTR. This means that the run segmentation for glyph processing is putting the numerals in a different run than the Hebrew letters, which are strong RTL. The punctuation characters are neither LTR nor RTL, but are bidirectional and which run they end up in for glyph processing—and hence for application or not of the kern feature—will depend on outcome of the Unicode bidi algorithm and on whatever logic InDesign uses for run segmentation.

I think this is why you are seeing the inconsistent results: in the top line the presence of the Hebrew letters is creating a strong overall RTL directionality for everything except the numerals, meaning that the punctuation is in RTL glyph runs, while the numerals are in LTR glyph runs. Meanwhile, in the bottom line, the punctuation is in the same LTR glyph runs with the numerals.

Unfortunately, there is no way around this at the font level. Almost 10 years ago I initiated conversations between shaping engine developers about possible uni-directional GPOS handling, which would enable kerning independent of character directionality, but it never proceeded beyond speculation about possible solutions.

In theory, someone could insert Unicode directional formatting control characters into the text to affect explicit directionality for punctuation, overriding the bidi algorithm results, but I don’t know whether this would trigger appropriate run segmentation. One of the long-standing issues with OpenType Layout is that there is still no formal standard for how to perform run segmentation, so there are inconsistencies between implementations.

Ori Ben-Dor

Thank you, John, I understand the issue much better now.