Greetings All,
I’ve gone down the rabbit hole of OpenType feature support by various applications and could use some help in understanding the policies that Microsoft Word applies -it appears to be the odd application out that interprets features differently.
What I am observing is substitutions (in a calt, liga, other) appear to work for a Latin symbol sequence, but not non-Latin. Perhaps Word requires additional language configuration? I reduced the problem to this minimal features.fea file (FontLab 8 is my design tool):
languagesystem DFLT dflt; # I add this line only languagesystem latn dflt; # added by FL8 languagesystem ethi dflt; # added by FL8 languagesystem grek dflt; # added by FL8 feature calt { sub a b by x; # works everywhere sub h a by uni1203; # works everywhere sub uni1200 a by uni1203; # fails everywhere sub h uniFE00 by uni1203; # fails in MS Word, works for LibreOffice & Chrome sub uni1200 uniFE00 by uni1203; # fails in MS Word, works for LibreOffice & Chrome } calt;
In summary, I see for MS Word the following is ok:
sub <latin> <latin> by <any>;
but not:
sub <latin> <non-latin> by … ; sub <non-latin> <non-latin> by … ;
and universally failing is:
sub <non-latin> <latin> by … ;
I would like to understand why these fail and what missing OT statement MS Word is in need of. To be fair, I haven’t tested with Cyrillic, Greek, etc. , so “non-latin” is limited to Ethiopic, Sequence Variants, and PUA symbols in my trials.
Any help is appreciated!
Thanks,
-Daniel
Comments
Shaping engines divide a text string into separate segments. These segments can only hold one Script. The OpenType layout features are processed per segment, so therefore mixed scripts will never work.
The shaping engine used by Microsoft Word is outdated, so not all features work as they should.
thanks again!
Word (on Windows) uses DirectWrite for text shaping. Notepad also uses DirectWrite, and for testing DirectWrite I would use both applications. I have encountered situations where Word would not apply liga by default (but could be enabled by the user), but would apply rlig by default. Notepad applied both with no user interaction.
From reading the Variation Sequences FAQ you need to be using a variation sequence that is known by Unicode.
And those that do may not handle it consistently. There is no formal specification for how to perform OTL script itemisation and run segmentation, and different software makers have implemented it without common agreement. So, for example, I have found different results for script=Common integration into runs in Microsoft and Adobe shapers.
Really, this is something for which a standard algorithm is needed, one that would account even for edge cases such as adjacent sequence of different scripts with a script=Common character between them.
Adding a couple of VS entries into the UFO lib.plist, building and installing the font. The VSs were accepted by MS Word! Unfortunately, FL8 was not including color data in its UFO export so that became a new obstacle (I reported the issue to tech support, this may simply be an export limitation).
With FontCreator, I could open the COLR OTF file, add the VS mappings, and this finally worked as desired in Word. I'll test thoroughly during the week, at the moment it appears that I have a viable workflow.
thanks, again!
I cannot find either "h uniFE00" or "uni1200 uniFE00" from the original question in any of the above references, though maybe I missed them. Are these the sequences you found were accepted by MS Word?
Also, as for
not seeming to work, I can confirm that in Word 2016 on Windows 10 such sequences do work for Arabic.
Are they the same non-Latin writing system?
e.g. is expected to fail, but
should work
Regarding the observation by @bdevos , I found that Word and other apps, and the font rendering stack, are not enforcing the definitions in the StandardizedVariants.txt, etc. , files as a permittable set. I was able to add my own custom Variation Sequences -fortunately (in the cmap). I interpreted those files as more of a reference for font vendors who want to support variation sequences.
@Thomas Phinney , it was the 1st, mixed-script case that was failing. I hadn't tried the 2nd case, it seems more sensible that it should work.