I.sc.ss01 vs I.ss01.sc, and feature generation

I have a font with an I.ss01 and an I.sc.ss01. The problem is that Glyphs does not include I.sc.ss01 in the automatically generated c2sc feature. If I name it I.ss01.sc then it is not included in the ss01 feature.

Is there an elegant way to solve this? Would it be possible to tweak the automatic feature generation in Glyphs to build both?

Somehow, Glyphs does get multi-extenstion composites right, like Iacute.sc.ss01 built from I.sc.ss01 and acute.sc, which impressed me. It would be cool if feature generation was similarly smart to understand what I want.

It should work if you keep the suffixes in the order of the opentype features. If it does not, then you discovered a bug.

the I.sc.ss01 should not show up up in the c2sc feature, only in the ss01 feature. This glyph should only be used if both features are active and so the c2sc feature activates the I.sc and the ss01 switches to I.sc.ss01. Thats why the order of the features is important, they have to be applied in that order.

Thanks, that makes perfect sense. In previous fonts I produced, I always put the substitution in both features but that’s not necessary (although it doesn’t hurt).

Now I have another tricky problem I cannot solve automatically.

My font has a z with descender, named z.ss07. It also has a tz ligature with descender. So, the tz ligature is to be built only if ss07 is active. This means that the liga feature must be after ss07, right? Now, the question is how to name my tz ligature. “t_z.ss07.liga” does not generate the substitution in the liga feature.

Also: How does the automatic generation of dlig work? Adding .dlig to my ligatures does not generate the substitutions automatically.

Some more weirdness: I cannot name my glyph f.ss08_i.liga – Glyphs automatically removes the “.liga”. Why is this? Then, it automatically generates f.ss08_i in dlig, not in liga where it would belong. Huh?

No suffix. All ligatures go into dlig by default, except a few f ligatures. Try f_i.ss08. f_i is one of the ligatures that go into liga by default.
This does not work, unfortunately. It does not generate anything in any feature. How about this question?

I guess these cases are too unusual to be covered by automatic feature generation?

Ligatures with suffixes are quite difficult because you never know if the suffix belongs to the hole ligature, or to one of the glyphs. And adding the suffix to the first component don’t work, either as everything after the first period is just suffix (this might cause the problem with ‘f.ss08_i.liga’

I wouldn't agree with "never". If the suffix is before an underscore then you do know that it belongs to the substituted glyph, not the whole ligature. It is not ambiguous (assuming underscores are not used in suffixes). One could simply change the rule to say that everything that comes before an underscore (or between two underscores) is to be treated as a glyph name. Giving underscores the higher priority than the period.

I would make the automatism assume that suffixes generally belong to the individual glyphs (i.e. split the whole name by underscores first), and only if these do not exist in the font, treat the last suffix as referring to the whole ligature.

I will think about that. Thanks for the suggestion.

This feature of Glyphs would be great. But how to solve the glyph name on export? You can have for instance ligatures:
But to keep the glyph name right, you have to always export f_i.suffix. So what about double suffices divided by underscore? It might require a suffix for no suffix :slight_smile: The top example would become for instance:
Or maybe instead of zero-suffix, we can skip the suffix at all:

This is actually a really good idea to solve the problem. So we don’t only add the suffixes at export time but use your approach in the file, too.

So it works like this:
if you have a ligature and just add a suffix (e.g. f_i.ss01) then this is a stylistic alternate to the f_i ligature.
if you need to be more specific, add a ‘suffix ligature’, like f_i.ss01_ss02. That means this is a ligature of f.ss01 and i.ss02.

There is another problem, through. The ss01 feature usually is supposed to come quite late in the feature list. So the stylistic alternates are not yet there if the liga (or dlig) features is applied.

Georg, I am aware of it. One solution is to rearrange features automatically when the font contains ligatures made of glyphs from two different sets. Another possibility is to display a warning on export asking users to rearrange features manually.
I know it is quite complex because you can also have small caps involved, imagine a ligature of “T”+“h.smcp”+“e.smcp.ss01”, what would be the right name? T_h_e._smcp_smcp.ss01?

Maybe we write a script for this and that could also handle the reordering and would be adjustable for every need?