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

[Dave Crossland]

On Fri, Aug 21, 2020, 4:55 PM Andrew Glass <Andrew.Glass at microsoft.com>
wrote:

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.



I'm confused - it seems from a discussion on another thread (below) that
"indic 3" was an idea floated a a few years ago, but it's been at a dead
stop for a while... Is that right?

I'm guessing because of the regression risk to existing working fonts?

It seems to me that a backwards incompatible format will then be needed, as
Li Renzhi says.


On Fri, Aug 21, 2020, 8:01 PM Renzhi Li <Renzhi.Li at microsoft.com> wrote:

> 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.
>
>
This would be very helpful for the Noto project, where I'd like to see a
single Noto Sans that has everything in it.


>    - 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
>
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200821/c5a468ab/attachment-0001.html>