Cross-script OpenType feature?
Adam Jagosz
Posts: 689
I've been wondering if it is possible to define a substitution rule for a letterpair consisting of two letters from different scripts, say, Latin and Greek? From what I tried, it seems impossible, I created some classes containing glyphs from mixed scripts and I defined lookups for them which I included in features for both scripts, and it didn't work.
I don't like the idea of scripts and language systems in OpenType scripting, I've always thought it was only limiting the designer. The only useful purpose of this system seems to be the localization feature. Am I wrong?
I don't like the idea of scripts and language systems in OpenType scripting, I've always thought it was only limiting the designer. The only useful purpose of this system seems to be the localization feature. Am I wrong?
Tagged:
1
Comments
-
I should think it would work fine if the rule is registered under DFLT dflt.
0 -
No, you can't mix scripts, as such text will be split up in separate segments.
OpenType layout engines should work the same, but don't. For example a kern pair which includes a space character will work in Word, but fails in Firefox.
3 -
This matter becomes more complex when the direction of the script changes. So it becomes very hard to process the shaping on both scripts in a same segment. Take the following sequence of Unicode string:
Latin فارسی
This sequence is stored in the memory in this order:
L
a
t
i
n
ف
ا
ر
س
ی
You see how the order is different from what you see in the top sequence. Because the order of the string in memory is in the order which was typed by the user. In the final display the first word is written left to right and second word is written right to left. Before applying the OpenType features every segment of scripts will be separated to avoid problems with directions. I'm not sure why this would happen with scripts with same direction though. This behavior could defer in different shaping engines.
2 -
Shaping engines segment text strings based on Unicode script property, so the Latin and Greek glyph end up in separate glyph runs. This means that they're never processed together, and hence any lookup that requires them to be processed together will fail.
You could try Kent's suggestion (putting the relevant lookup under the DFLT script tag), but I'm not hopeful that it will work reliably. It may work if the DFLT script is the only one in the font, but if the font also contains latn and grek scripts, these will probably override anything in DFLT.
5 -
Agree with John. I will be surprised if you find (m)any layout engines that do not break the text run depending on writing system (script), regardless of how the features are set up in the font.1
-
For example a kern pair which includes a space character will work in Word, but fails in Firefox.
Firefox is able to handle OpenType features across space for a few years now (though fonts having such features will not benefit from shaped work caching in Firefox and Chrome which might negatively affect text rendering speed, especially for large amounts of text).
2 -
@Khaled, you are right as it now seems to work.
It is still good to be aware the layout engines don't produce 100% identical output, so better test specific features within web browsers, word processors, and type design software.
1
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports