True, the Unicode names in FL were irritating, but when looking for glyphs to collect in a Kerning or Spacing Group, I usually don’t look at their names, but rather what they look like. Especially when I am not familiar with the names of script system. So a visual interface which allows to visually check and change the contents of Kerning and Spacing Groups would be ideal to me. Being able to sort the contents of a group (Script System, Name, Unicode, manually) would be great too.
Do not mix scripts in a kerning group. Especially not when they have different directions.
If you sort by Unicode and most or even all of the glyphs do not have a Unicode (frequent scenario in Arabic), how should it sort?
What’s the point of sorting a kerning group? Especially manually?
The class-centric approach of FL is to treat kerning groups as OT classes like any other and you need to assign glyphs to the class. Glyphs follows a glyph-centric approach where the group is assigned to the glyph. That has a few advantages: you cannot accidentally have the same glyph in multiple groups (a frequent source of errors in FL4 and 5), and it is easy to find all glyphs still unassigned.
There is a Show Groups in the View menu that overlays all group members for the current pair in the Edit tab, so you see what you are doing when you are group kerning. And there are plug-ins and scripts that help with the kerning, including finding similar shapes.
It can handle it just fine. But it is cleaner in Glyphs 3 where each direction has its place.
That was the reason to have separate LTR and RTL kerning. That way you can decide where each pair goes. The script is similar to what Glyphs 2 would do on export when it tries to separate the RTL and LTR pairs to put them in the correct lookups. And as you see the problems with the script, you might have those problems in Glyphs 2, too.
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…
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.
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.
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?
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*.