ela geminada - revisited
Kent Lew
Posts: 937
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?
3
Comments
-
I suspect so. I think one might have to just test it, though.
I am particularly thinking of older Adobe environments.0 -
I suspect so.
You suspect it would be as robust/reliable? Or you suspect there would be environments that support the GSUB but not the GPOS approach.
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.)
0 -
using OpenType layout features to steer l' periodcentered' to the encoded ldot may not be robust, in terms of spell-check and search functions.
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.
1 -
Please test underling the text in various environments. I had problems that shifting glyphs up (in the case feature) would shift up the underline, too.
0 -
Kent Lew said:
I suspect so.
You suspect it would be as robust/reliable? Or you suspect there would be environments that support the GSUB but not the GPOS approach.
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.)
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.0 -
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.
Actually, this is exactly the issue that I believe the Catalan users have with the sub l' periodcentered' by ldot; approach to {locl}.
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:- using OpenType layout features to steer l' periodcentered' to the encoded ldot is not desirable, in terms of PDF search functions.
1 -
Please test underling the text in various environments.
You’re right, Georg: In InDesign, the underline below the re-positioned periodcentered is indeed shifted up and to the left. Thanks for that pointer.
0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 798 Font Technology
- 1K Technique and Theory
- 617 Type Business
- 444 Type Design Critiques
- 541 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 498 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports