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’!
I finally got a chance to test the kerning as recommended. It worked perfectly. I don’t know if there was a GUI update in the meantime or I was just very confused.
The key is to preview the kerning pair in RTL setting. This way the kerning value in Info Box moves from left to right, and vice versa. Same thing for kerning Group names. And the visual preview is correct if it is viewed in RTL. If viewed in LTR, it can be confusing [as it was for me!]
I fixed that confusion for the next big version of Glyphs. It needed some changes at the internals that changes the behavior a bit and I don’t like to do that right now.
Can you be more specific? I know there is an issue in the latest stable version that is fixed in the latest beta. It took a bit longer to finish it but we hope that we can publish it soon.
Here is a screenshots from Glyphs 2.6, Indesign CC 2019 and TextEdit with a sample text.
As you can see, kerning in Glyphs “seems” to be ok, but when testing, it outputs inverted value (I checked the kerning values with Fontlab 6 and it wad inverted)
