[MPEG-OTSPEC] [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?

[Norbert Lindenberg]

Another issue for transitioning scripts that are supported by separate shaping engines to the USE: The cluster models assumed for validation may not be compatible. That’s not a font issue, but a text issue – text that renders fine when routed to an Indic shaping engine may have dotted circles inserted when routed to the USE, and vice versa. I’m currently investigating this area for Devanagari, and it’s not looking great.

In addition, the USE cluster model has incompatibilities with Unicode normalization, e.g., for Vedic cantillation marks.

For the USE to become truly universal, it will need to accommodate a variety of cluster models.

Best regards,
Norbert
Lindenberg Software LLC



> On Aug 22, 2020, at 09:07, John Hudson <john at tiro.ca> wrote:
> 
> On 21082020 8:50 pm, Dave Crossland wrote:
>> The number of indic fonts created in the next 25 years is... Not in terminal decline :) I don't want to say how many multiples than the last 25 years... But anything we do to make it easier for the next generation of type designers around the world is, I think, impactful work. 
> 
> Yes. I just wouldn't assume that using Indic 3 instead of Indic 2 is necessarily making things easier for type designers.
> 
> USE pushes more responsibility onto font makers than was the case in the script specific shaping engines. I think it is right to do so, because of the benefits to users in being able to get scripts supported in software more quickly (even to getting support implemented before a script is formally published in Unicode, as Andrew and I demonstrated for Soyombo*), but the flexibility of the USE cluster model comes at the cost of requiring font makers to have a deeper understanding of OTL and to look after more aspects of shaping at the lookup level. In that respect, making OT fonts for USE is more like making Graphite or AAT fonts: the shaper is doing less of the work for you, and you need to set up features and lookups to drive the shaping; indeed, for the features that produce reordering, one could say that the OT paradigm is reversed and rather than the shaper applying the feature the feature is applying the shaper.
> 
> One of the things I didn't discuss during my TYPO Labs presentation on USE** is the requirement to implement format control character behaviours at the GSUB lookup level, rather than relying on script-specific knowledge at the shaping engine level to apply particular features based on string analysis. So the font maker not only needs a deeper level of OTL knowledge, but also a deeper level of Unicode knowledge.
> 
> And that's all fine, and a lot of people will be up for it. But it is a paradigm change in OT font making, and it involves some things getting harder, not easier.
> 
> JH
> 
> 
> * http://tiro.com/John/Hudson-Soyombo-DECK.pdf
> 
> ** http://tiro.com/John/Universal_Shaping_Engine_TYPOLabs.pdf
> Video : https://www.typotalks.com/videos/john-hudson/
> 
> 
> -- 
> 
> John Hudson
> Tiro Typeworks Ltd    www.tiro.com
> Salish Sea, BC        tiro at tiro.com
> 
> NOTE: In the interests of productivity, I am currently
> dealing with email on only two days per week, usually
> Monday and Thursday unless this schedule is disrupted
> by travel. If you need to contact me urgently, please
> use some other method of communication. Thank you.
> 
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec