I’d like to revisit this topic, which has been touched upon before in previous discussion (such as the R.I.P. and Periodcentered threads).
It seems pretty clear that
However, chafing against the idea of having yet more duplicated glyphs to manage, just in order to solve a specific positioning situation, I was wondering if one couldn’t just use a GPOS rule to accomplish the same thing. For example:
This is language-specific; it contextually targets the periodcentered when between the two ls and shifts it closer to the first, up as necessary, and reduces the advance width before the second.
I’m wondering if anyone can think of a good reason why this would be a less robust solution than the GSUB approach. Are there environments which would not support this GPOS rule when they would support the GSUB?
It seems pretty clear that
- for whatever reason, most Catalan users have not embraced the encoded ldot U+0140/013F characters;
- the most common input sequence for ela geminada (ŀl) is /l/periodcentered/l — using U+00B7 for the punt volat (which is readily accessed by Shift-3 on a Spanish keyboard);
- using OpenType layout features to steer l' periodcentered' to the encoded ldot may not be robust, in terms of spell-check and search functions.
However, chafing against the idea of having yet more duplicated glyphs to manage, just in order to solve a specific positioning situation, I was wondering if one couldn’t just use a GPOS rule to accomplish the same thing. For example:
language CAT;
lookup lgeminada {
pos l periodcentered' <-91 50 -180 0> l;
pos L periodcentered' <-261 64 -250 0> L;
} lgeminada;
This is language-specific; it contextually targets the periodcentered when between the two ls and shifts it closer to the first, up as necessary, and reduces the advance width before the second.
I’m wondering if anyone can think of a good reason why this would be a less robust solution than the GSUB approach. Are there environments which would not support this GPOS rule when they would support the GSUB?