For a font that I’m working on Glyphs (builds 1064 and 1116) generates the following code:
lookup mkmk_mkmkthai_bottom {
lookupflag MarkAttachmentType @mark_bottom;
script thai;
pos mark [phinthu-thai] <anchor -76 -182> mark @mark_bottom;
// etc
} mkmk_mkmkthai_bottom;
The “OpenType™ Feature File Specification” says:
When a "script" statement is seen, the language attribute is implicitly set to 'dflt', and the lookupflag attribute is implicitly set to 0.
This means the generated code is effectively
lookup mkmk_mkmkthai_bottom {
script thai;
lookupflag 0;
pos mark [phinthu-thai] <anchor -76 -182> mark @mark_bottom;
// etc
} mkmk_mkmkthai_bottom;
Looking at the generated font file using ttx I see that it is compiled that way, i.e. the lookup flag is 0 (in the subsequent lookup mkmk_mkmkthai_top however makeotf chooses to leave the lookup flag intact).
Can you change Glyphs to generate the script statement before the lookupflag statement, to ensure that the lookup flag is respected?
I actually worked on that yesterday. And in this case, I removed the script tag as the lookup will be called again with the script further down.
But thanks for the reminder. And yes, makeOTF is doing all kind of funny business with the lookup flags. They even stay intact outside of the lookup. That’s why you see a lot ‘lookupflag 0’ in the code.
In build 1122, I see that this bug has been fixed. However, the change also has the effect of making the mkmk lookups, which in my font only affect Thai and were previously only included in the mkmk feature for the Thai script, available to all scripts in the font. That seems unnecessary and may adversely impact performance. Why was it done this way?
In a lot scripts in southeast asia, languages are not properly set in documents. Putting the lookups in DFLT and the actual script makes the font work in those situations.
The way I understand OpenType, language and script are determined separately. The language depends on information in the document, and, as you say, documents often don’t carry language information. The script, on the other hand, is derived from the characters in the text to be rendered, based on Unicode data, and doesn’t depend on any other information. The rendering engine breaks the text into script runs (“items” in the Uniscribe documentation), and then feeds the runs to the appropriate shaping engines.
If you have text in the Thai script, the font has Thai script information in its GSUB and GPOS tables, and the rendering engine has a Thai shaper, then the text will be processed by the Thai shaping engine using the lookups specified for Thai. Otherwise the lookups for the DFLT script will be used, and Thai happens to be one of the few Brahmic scripts where that might still produce acceptable results. But Thai text should never be processed with the lookups specified for latn or mym2 or any other script.
Did I misunderstand something? Or are there renderers that don’t follow this model?
To use both, the script and DFLT was the only solution to make it work in most environments. Those were mostly Firefox, Indesign and MSOffice. Some of the issues, specially in Firefox might be fixed in newer versions.
What I mean is, there’s not much point in duplicating MARK and MKMK lookups for DFLT if the other features work only for THAI. All features should be treated the same. Are they?