Organization of Classes

Is there a reason you starting with Glyphs 2 instead of Glyphs 3?

  1. Paranoia. Again. ( mostly reasond by so many FL4/5 Bugs and glitches over the years ) You remember the problems with the kerning conversion of RTL kerning?
    Glyphs 2 seems to be OK, so…

  2. My problem with the class management in Glyphs led to the idea to do this in FL7. But FL7 don’t im-and export the new Glyphs format.

What do you use those classes for (arheigth1/2)?
It is for a feature, that switches the ascender height of arabic glyphs.

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.

1 Like

Ralf, I am a recent convert to Glyphs but I use version 3. Although it can be frustrating to change your working ways from FL5 to Glyphs, it is well worth the effort. It just takes some time to.

1 Like

Don’t RTL kern in Glyphs 2. You can keep the RTL kerning clean in Glyphs 3, you cannot in Glyphs 2. In Glyphs 2, the RTL and LTR kerning pairs were not directionally separated.

So one could end up with weird kerning pairs, and difficulties when kerning between non-directional symbol and directional glyph.

There is a problem when converting between the two ways when the kerning groups are not directionally clean. And that is very difficult to resolve.

  1. Do not mix scripts in a kerning group. Especially not when they have different directions.
  2. 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?
  3. 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.

1 Like

I am really confused. You say, that Glyphs 2 do not produce correct RTL kerning?
This should have been mentioned somewhere, did it?

Anyway. For me it seems to work. The following example worked with indesign correctly

But imported in Glyphs 3 and processed with the 2 to 3 script, it looks like this:

So, it is impossible to convert RTL kerning between directional and non-directional glyphs reliable?

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.

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…
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

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?


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?