If I add .calt or .salt at the end of a glyph, in the feature, it does not add as a default
calt is a context alternative. Glyphs cannot know the context in which to use the .calt variant instead of the main glyph, that requires manual feature code.
I mean like liga and dlig use for two pairs
Is it possible?
liga and dlig are ligatures which combine multiple glyphs to a single glyph. That single glyph then gets the .liga name suffix. For example, f and l combine to f_l.liga. The generated feature code
sub f l by f_l.liga;
can be derived from the name f_l.liga alone.
With calt, there is also a context of multiple glyphs (like with f and l in the ligature case), but typically not all of those glyphs are replaced, only some of them (most times just one).
For example, for f and l, you could design a shorter f that does not collide with the l, let’s call it f.short. Then, in calt you add a rule:
sub f' l by f.short;
This would be difficult to express in a glyph name. It would need to be something like f.followedBy_l.calt. But that only works in the simplest cases, there is often calt code like
sub f' @tallAscender by f.short;
or even
sub @a b' c by b.alt;
which is much more difficult to express in a glyph name.
Thanks, but I didn’t understand why that was too difficult. If I have b_c.calt, the code must be like this:
sub b c by b_c.calt;
Just for 2 pair glyphs so I can use calt like liga and dlig. Also for b_c.salt
But why do you like to do hat in calt? That is not a contextual alternate but a ligature. You can use b_c.liga or b_c.dlig.
Because in Arabic we have many ligatures, this helps me to categorize ligatures better
Remember .calt and .salt add two categories and this is very helpful
What happens if I have b_c.ss01
Is it possible to have this feature as an auto
sub b c by b_c.ss01
No. Not with stylistic sets. You would need to put this into a ligature feature.
The different categories are helpful because they describe different kinds of feature code. Adding ligature code into calt would somewhat defeat the purpose of those categories.
Maybe there is a different way you can organize your glyphs and feature code? Perhaps using some other Glyphs features like tags, Smart Filters, or something else? If you can describe your needs in more details, we might be able to find a better fit for that workflow.
Why not? I added this code myself, and it works. The question is, when it works correctly, why is the code not written as auto?
No, I dont want to categurize in glyphs app but in export file,
like this: behDotless_alefMaksura-ar.fina.liga can turn on or off with ligature. behDotless_alefMaksura-ar can turn on or off with discretionary ligature
and I want use calt and salt as well for 2 other type of ligatures. every liga, dlig, calt or salt contain 20-30 ligature and I want user can control which type of ligature was on or off.
Of course it works, but you’re asking about automatic generation. Semantically, it makes no sense to substitute two glyphs by a stylistic set variant of their ligature in one go. So why should Glyphs generate this code automatically?
What you can do instead:
# liga or dlig
sub a b by a_b.liga
# ss01
sub a_b.liga by a_b.liga.ss01
If you have these glyphs in your font, Glyphs will generate that code automatically.
Yes, why do you need b_c.ss01 if you don’t have b_c?