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

[Peter Constable]

+1

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Andrew Glass
Sent: Friday, August 21, 2020 1:25 PM
To: John Hudson <john at tiro.ca>; mpeg-otspec at lists.aau.at
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?

> JH: [With regard to the latter, there was recently a discussion on the 
> Noto repo regarding whether scripts with very simple layout 
> requirements should be passed to USE*. My inclination is yes, they 
> should, and that any newly supported script should be passed through 
> USE regardless of the simplicity or complexity of shaping 
> requirements. It would be helpful to know the position of the USE 
> implementers on this.]

I agree. With recent updates to Windows Shaping (DWrite &  Uniscribe), we have been pushing newly encoded scripts into USE regardless of whether they are complex. This approach avoids the problem of determining whether a script meets a particular complexity bar - and avoids cases in which one might get it wrong and underserve a script that has a non-obvious complexity requirement. The only downside I know of for pushing a script to USE that could be satisfied by a simpler engine is a minor perf impact-scripts may take longer to render when shaped via USE. However, the delta is negligible for most use cases and that would certainly be the case for scripts being newly encoded.

There is one more caveat, if during the encoding process within Unicode, a proposed script had special shaping requirements that would not be met by USE, then that would need to be captured and communicated clearly to implementors.

Beyond that, I agree with John, existing engines need to be maintained so long as existing fonts would not be 100% compatible if shaped via USE. That is certainly the case for Indic 1 & 2 tags, hence the goal of supporting Indic 3 via USE. Other script-specific engines have challenges which we investigated during USE development. Some of those are likely solvable with new classes and work in USE. Personally, I would like to see that happen so that maintenance costs associated with keeping engines current with Unicode can be minimized.

Cheers,

Andrew

-----Original Message-----
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of John Hudson
Sent: Friday, August 21, 2020 12:28 PM
To: mpeg-otspec at lists.aau.at
Subject: [EXTERNAL] Re: [MPEG-OTSPEC] Shaping behavior standardization: multi-engine or "Super USE"?

On 21082020 12:13 pm, Renzhi Li wrote:
> Therefore, for the shaping behavior standardization, should we 
> standardize all the existing engines (focus on the "status quo"), or 
> work on USE extension to use one single engine for every script?

Both.

We do need to ensure that the existing engines provide consistent results for existing fonts built to those specs, even if we also provide mechanisms to pass scripts to USE instead.

The USE layout model is both general and particular: it requires fonts for scripts with complex shaping requirements for correct text display to be made in a very particular ways, which are not compatible with the methods used in fonts for existing shaping engines. So passing any script that currently goes to a dedicated engine through USE is going to require new script tags (or another special convention, e.g. a generic script tag. Even simple scripts might involve some different methods when being passed through USE, and would need to be considered cautiously.

[With regard to the latter, there was recently a discussion on the Noto repo regarding whether scripts with very simple layout requirements should be passed to USE*. My inclination is yes, they should, and that any newly supported script should be passed through USE regardless of the simplicity or complexity of shaping requirements. It would be helpful to know the position of the USE implementers on this.]

JH


* https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgooglefonts%2Fnoto-fonts%2Fissues%2F576&data=02%7C01%7C%7Ccd0870e4dfe3465e261e08d8461478e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336401034523481&sdata=zUCmcOz%2FQipIQ35nUE3j%2F4hnxhT1jNvUt9nY2luoZzo%3D&reserved=0


-- 

John Hudson
Tiro Typeworks Ltd    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7C%7Ccd0870e4dfe3465e261e08d8461478e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336401034523481&sdata=8PHaSxA%2FGnN5PHe8tvLxCfyepE%2Ff3mZ%2Bh5FX9ghdSbE%3D&reserved=0
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7Ccd0870e4dfe3465e261e08d8461478e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336401034523481&sdata=Rxo0hzXcjSwc9RgpQfGx5v4fWk%2Fzk0ZLoaM34Jnl2VI%3D&reserved=0
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7Ccd0870e4dfe3465e261e08d8461478e7%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336401034523481&sdata=Rxo0hzXcjSwc9RgpQfGx5v4fWk%2Fzk0ZLoaM34Jnl2VI%3D&reserved=0