Nope, what i see in Glyphs 2 is the same as in Indesign. So the export seems to be different to the script…
I said similar, not the same. And Glyphs 2 should do a better job than the script.
The script is looking for left glyphs, that should be in RTL order, right?
Why not just looking for right glyphs, too?
I think, every kerning pair, that contains a RTL glyphs, is intended to be RTL…
2.
How is “isRTLScript” (found in the mekkablue script for kerning conversion, but not in python documentation) defined? Are all glyphs RTL, that have the script tag set to “arabic” or “hebrew”? In other words, can it be determinded by the user, even if a glyph has no unicode?
There are much more methods and stuff in Glyphs that is not in the docs (we are constantly expanding it, but adding everything would be too much and you wouldn’t find anything any more). If you like, you can check the headers in Glyphs 3.app/Contents/Frameworks/GlyphsCore.framework/Versions/A/Headers.
ok, but what do you think about the first question?
The lookups only care about the first glyph. And there is no kerning applied between LTR and RTL glyphs anyway. So about what pairs do we speek?
We speak about kerning between a LTR (or better “non-script”, because it will be used in all scripts) glyph like the “quoteright” and an RTL glyph like uni0642.
The Glyphs 2 file opened in Glyphs 3 with script applied does not convert the pairs with an RTL on the right side to RTL but leaves it as LTR ( as shown before). Because the script only checks the left side of a pair.
Glyphs2, correct in RTL mode:
Glyphs 3 in RTL mode. Value is missing, because it is still LTR:
The result is a missing value in Indesign or everywhere else.
So, I think it would be necessary to convert every pair, that contains an RTL glyphs, no matter, if left or right. And there are a plenty of possible “non-script” glyphs:
"()*,-.:;?{}~«®°²³º» and so on, depending on the design…
not to forget the numerals, which are always LTR, even in hebrew or arabic.
I hope this was understandable, as English is not my first language.
I see. I’ll have a look.
One could treat A O, Alpha Omicron and A-cy O-cy the same way and split the groups when kerning is done. Or ist there a way to make groups behave identically?
understood
I haven’t done Arabic yet, so I wouldn’t know an answer to that question. But many characters, such as zhe-cy.loclBGR (ж with an ascender) are glyphs representing a character that actually have a unicode (ж, i.e. uni0436), so when having to sort to unicode, I think there are ways to find appropriate solutions for many cases.
I’d like to sort because that could make comparisons between groups a little easier. Accents on top only, followed by stacked accents, followed by accents on top and below too. Yesterday I found out that a*.ss02 was missing acaron.ss02 because I sorted the kerning group while comparing it with a*.
I usually put all Latin, Greek and Cyrillic glyphs in the same class. Those are put in the same lookups anyway. But for Arabic and Hebrew it is another story. So do not mix Hebrew and Latin.
But in the case of numerals and punctuation marks you have no choice. Because they are used in all scrpts.
Those don’t have a script associated at all. And you can put them in classes together. Just try not to add some specifically RTL glyph to those classes
So I can assume, that the discussed behavior of Glyphs 3 is a bug and will be fixed?
I think you mean the problems with the script. Yes, we’ll improve it.
Ok. Thanks!
AFAIK it kind of works if you transgress script boundaries between Latin, Greek and Cyrillic, those three. Even office software does not complain. But I would not recommend for any other scripts.