I’m working on an Arabic typeface in Glyphs App and need advice on implementing a contextual substitution rule:
We want the word “ريال” (rreh-ar yeh-ar.init alef-ar.fina lam-ar) to be automatically substituted with the currency symbol ﷼ (U+FDFC) — but only when it appears after a digit, to reflect the currency context (e.g. 20 ريال → 20 ﷼).
However, we don’t want this substitution to happen in other contexts where the word “ريال” is part of a name or unrelated to currency — like in “ريال مدريد” (Real Madrid).
I tried writing a contextual substitution like this:
lookup ReplaceRiyalAfterDigit {
sub @Digits reh-ar yeh-ar.init alef-ar.fina lam-ar by Riyal-ar;
} ReplaceRiyalAfterDigit;
But this ends up replacing the digit itself, or doesn’t work properly due to the limitation of replacing multiple glyphs with one.
My questions:
What’s the best approach to implement this kind of context-aware substitution?
Is there a way to reliably substitute reh-ar yeh-ar.init alef-ar.fina lam-ar by uniFDFC only when preceded by a digit , while leaving other uses of “ريال” untouched?
Should this go into the calt or liga feature?
Are there best practices for handling currency-specific ligatures in Arabic?
I wonder if that works everywhere. As the digits are LTR and the letters are RTL, there end up in two different layout runs and context features don’t work between them.
The new riyal symbol should be encoded though. The proposal (not definitive, but likely) suggests 20C2, and it is common practice to reuse FDFC (which was originally intended for the Iranian Riyal). Currently, I would suggest double encoding the riyal glyph with these two.
Since it is a currency symbol, do not assign to any script, not even -ar.
The two riyal symbols aren’t the same though. The new one that’s added in Unicode 17 (U+20C1) is for the Saudi riyal, and the original (U+FDFC) is for riyal used in other countries. They should look different and be encoded separately.
Yep that’s correct, since it’s the only one encoded for a long time. Since the new Saudi symbol has its codepoint and will be added to keyboards in the near future, a fresh font should probably include both separately especially if the language coverage includes Persian.
As for the original questions, I would recommend your substitution code go into calt over liga if those are the two options. But I’m not sure how many environments it will work in. Most (all?) shapers flip directions from RTL to LTR once the digits occur which means that the context will never hit; once the direction changes it’s essentially a fresh text run and the digits won’t know anything about the RTL glyphs that came before. We put this substitution in dlig (discretionary ligatures) as a simple substitution (no digit context) that the user can toggle when needed.