Kerning in RTL (Right to Left)


Did anybody do RTL kerning successfully in Glyphs? My first attempt failed and while I’m trying to do it in a different way, I wonder if there is a tried and tested way to do it. I saw few topics on this subject but no clear answer and those topics are rather old and the forum notification discouraged me to revive them!

FontLab also had a problem with RTL kerning and despite several attempt to fix it, the problem persisted as much as I remember. It seems to be a a tricky problem partially because it is very hard to test it in Arabic text flow [with Hebrew should be easier].

Here is the rough idea about what seems to be the problem:
You apply kerning between B and C. Suppose positive value and ‘ABC’ turns to ‘AB C’.
To do this, you apply the positive kerning value to the right side bearing of the first glyph.
In RTL this kerning amount should be applied to the left side bearing of the first glyph.
It doesn’t matter in which direction we preview the characters in Glyphs, no matter which direction, we still put the appropriate left side bearing of one beside the right side bearing of the other. The main issue is which character is considered first and the kerning is applied to the right side bearing of it, regardless the kerning pair is LTR or RTL. In other words for that kerned ‘AB C’ sample the positive value kerning is applied to the wrong side of B in RTL context. Something like ‘A BC’


If, in the font, you add a positive amount to the /B right-side kerning to be applied when the /C appears to the right, it will always be spaced the same regardless of whether it is typeset LTR or RTL. It would not affect the /A in any way.

Think of the kerning as a temporary change to the right sidebearing of the /B.


That’s right George and this is exactly the problem in RTL! B is the first glyph in LTR mindset. In RTL mindset it is the second! Now if this temporary side bearing increase was applied to the left of C instead of to the right of B, my problem was solved!


After doing a simple test, I see what you mean; Glyphs is flipping the kerning values when the user changes the typesetting orientation. In my view, that isn’t the way it should work.


Glyphs currently has only one kerning list that doesn’t differentiate between LTR it RTL. Only on export the pairs between RTL glyphs are put into a RTL lookup. If you apply the kerning in RTL mode, that works fine.
I know that this setup is not ideal but couldn’t fix it without breaking a lot existing file. I have properly implemented this in the future branch of Glyphs.

If you could send me a file that produces wrong kerning, I’ll have a look and fix it. But the examples with Latin letters doesn’t apply as they are never layed out in RTL, at least that would be new to me. Please try with Arabic letters.


Okay thanks Georg. I’m working on it. It will take a while. I’ll do the kerning in RTL mode [again] and see what happens.
But if it didn’t work [which I suspect!] and until the future branch of Glyphs is out, it is a good idea to create a little utility that fixes the RTL kerning of the font on the output. As complicated as it sounds to be in implementing in the font editor, it seems to be an easy fix on the output.
In fact, I did my RTL kerning in FontLab back then. What happened was that I was testing my fonts in Mellel text editor which has a very good RTL support. I first thought the problem was with Mellel and reported it to them. Eyal Redler the developer, was nice enough to write a little utility to fix the kerning of the font on the output. And I ran all my fonts through that utility and it worked perfectly. But that utility doesn’t even open in today’s Mac OS.
I’m sure you don’t want us to send you a font to be fixed, each time we click on ‘export’!


There are plenty people that make perfectly fine, functional Arabic fonts for years now.