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

[Renzhi Li]

Enabling cross-script shaping may introduce an API break, and if we need that, it should be done in the OT2 story.

Other possible API-beraking chagnes include:

  *   32-bit GID
     *   Breaks DW and CoreText, which defined GID explicitly to UInt16.
  *   GSUB-GPOS-tangled shaping (i.e., placement-dependent substitution)
     *   Breaks DW as it perform GSUB and GPOS in different API calls.
     *   HB is not influenced; not sure about CT.

Yours,
Renzhi
________________________________
发件人: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> 代表 Andrew Glass <Andrew.Glass at microsoft.com>
发送时间: 2020年8月21日 16:47
收件人: Peter Constable <pgcon6 at msn.com>; John Hudson <john at tiro.ca>; mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
主题: Re: [MPEG-OTSPEC] 回复: [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?


Cross-script shaping support and the abilty to apply locl features to specific glyphs based on BCP-47 tags sounds ideal to me.

Andrew


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Peter Constable <pgcon6 at msn.com>
Sent: Friday, August 21, 2020 4:32 PM
To: John Hudson <john at tiro.ca>; mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] 回复: [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?


Well, that certainly seems like a reason why language systems and features need to remain organized by scripts.



Now, in some OT2.0 future, maybe new formats could be created in which language systems don’t use OT tags at all but use BCP-47 tags directly. Then that would address that issue. And if ‘loc’ features were organized that way but other features don’t need to be shoe-horned into that structure, we could still have features applied script boundaries triggering lookups that can act on glyphs of whatever scripts.





Peter



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



On 21082020 1:52 pm, Peter Constable wrote:

Thirdly, if there is one shaping engine for all scripts, would there be any need at all for LangSys and Feature tables to still be organized hierarchically under different script tags? (That’s another existing obstacle to glyph actions across script-run boundaries.) IOW, instead of a new _set_ of script tags, would just _one_ new “script” tag suffice?

That’s where my mind started going today. But I'm not sure all the issues that arise can be resolved in that model.

If itemisation and glyph run segmentation is not performed on the basis of script tag, and everything using the new USE tag gets processed as a single run, how do we handle characters with locl substitution forms specific to individual scripts? And if such characters are Unicode script=common, are we pushing the segmentation down a level rather than removing it?

J.

--



John Hudson

Tiro Typeworks Ltd    www.tiro.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7Crenzhi.li%40microsoft.com%7C8535f469b6e14d27ccdf08d8462ca963%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336504937408228&sdata=Bv4qmJVNOQ7090lRiMZ%2BSkktoxiBelveVcQPNhOjJxc%3D&reserved=0>

Salish Sea, BC        tiro at tiro.com<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200822/fff802e9/attachment.html>