I'm not sure whether this is the best public place to ask; the man who could best advise on this implicit subquestion is probably
@Peter Constable.
A sad feature of Tai Tham font development (though Apple may laugh) is that the best way of developing a Tai Tham font, though perhaps not for the faint of heart, is to avoid the Universal Shaping Engine (USE). With the HarfBuzz renderer, this can be done straightforwardly by having no script table in GSUB or GPOS for the script in question. The shaping and positioning are then done according to the features provided for the default script ('DFLT'). This also seems to work for CoreText.
I am not clear what the behaviour is intended to be on Windows 10. It seems to have evolved over the course of Windows 10, and I would like to know what the long term intention is and what the timescales are. In Notepad and Character Map, it seems that for a font with no GSUB or GPOS for the script in question, the USE will be run using features for the default script. For MS Word of Microsoft Office Standard 2016, it seems that the USE will be run with all features considered devoid of lookups, except that features for the DFLT script can be enabled in the normal fashion for MS Word. (There are some anomalies I have not yet worked out.) It seems the dotted circle will not be inserted if not present in the font. Will the MS Word behaviour change to that of Notepad? Or will there be a mechanism to opt out of the USE?
What happens with other renderers?
Comments
I like the idea that the absence of a particular script tag applies DFLT script shaping to characters regardless of Unicode script property. This provides a mechanism to bypass the directed shaping path for the characters. It seems to me unproblematic, and something that should be standardised so that developers know to do this.
But is it really the case that this is the best option for Tai Tham? Isn’t the better option either to revise USE to include some cluster model exceptions for Tai Tham, or to specify and implement an independent Tai Tham shaping engine?
I have seen the original issue of a script (Limbu in this case) being routed to USE in DirectWrite, even if the font only has DFLT.
The Grantha bindu below, which is used as a nukta with Tamil script, has the property script=Inherited, meaning that it should be combinable with any base character from any script. So it doesn’t matter that it is in a different Unicode block from Tamil, and the issue in DirectWrite is not architectural but just indicates that the Tamil shaping engine has not been updated to accommodate this character.
[Script itemisation and run segmentation is performed using unstandardised and/or undocumented algorithms. For characters with particular script properties, this process is pretty obvious, but the handling of adjacent characters with the property script=Common is not standardised.]
* Adobe is responsible for the DFLT script tag concept, but to my knowledge they never really documented what they do with it. Microsoft, as I recall, didn’t really see the point of it. HarfBuzz has implemented a use for it.
Sure, but that just means you are restricting input to the system, not that the system is designed with the intent of you being able to tell it what to do.