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
- 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.
One popular approach, recommended by the Glyphs team among others, is to contextually substitute an alternate
periodcentered.loclCAT that is fitted to naturally provide a suitable
ela geminada in combination.
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?
Comments
I am particularly thinking of older Adobe environments.
How far back is reasonable to worry about, do you suppose? It seems to work in InDesign CS3 in OSX 10.6.8.
Illustrator CS3, however, didn’t offer Catalan as a language option yet. I don’t see the option in CS5.1 either. So, to that extent, any localized approach won’t work. (Which is a separate issue that I’ve been pondering, for another thread.)
Glyph substitutions shouldn’t affect operations that are done on the underlying text stream, like spell checking or search. Searching the PDF, however, might be affected in some cases where the actual string is not stored in the PDF, but this can be handled by following Adobe’s glyph naming scheme.
I’m in favour of using positioning here, however, just to avoid needless glyph duplication and I doubt anything that matters today and can handle contextual substitution will not be able to handle the positioning.
I suspected there might be problems in some old Adobe places. But if it works in InDesign CS3 I think you are in good shape.
As you note, any solution relying on the 'locl' (locale) feature requires that the app allow you to tag the text as Catalan, or does so itself automatically. True of any implementation that uses language-specific behavior, though.
If I set a text in InDesign with “mil·lenari” tagged as Catalan and set in a font with the above {locl} substitution, and then generate a PDF, when I search the PDF for “mil·lenari” in Acrobat, it won’t find my original text. This is because the text string has been reconstructed from the glyph name ldot and is now “miŀlenari.” So, the search has become broken.
So, I should amend my third point above, for clarity: