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

Sat Aug 22 05:35:37 CEST 2020

The risk to existing working Indic fonts would be if software supported USE using Indic 3 tags but NOT using legacy Indic engines using Indic 2 tags. When we first created Indic 2 in Windows Vista, we continued to support the original Indic tags with the original behaviour intact. Back then, there weren’t that many Indic fonts to worry about.

Peter

From: Dave Crossland <dcrossland at google.com>
Sent: Friday, August 21, 2020 8:21 PM
To: Renzhi Li <Renzhi.Li at microsoft.com>
Cc: Andrew Glass <Andrew.Glass at microsoft.com>; Peter Constable <pgcon6 at msn.com>; 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"?

On Fri, Aug 21, 2020, 4:55 PM Andrew Glass <Andrew.Glass at microsoft.com<mailto: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<mailto: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<mailto:mpeg-otspec-bounces at lists.aau.at>> 代表 Andrew Glass <Andrew.Glass at microsoft.com<mailto:Andrew.Glass at microsoft.com>>
发送时间: 2020年8月21日 16:47
收件人: Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>>; John Hudson <john at tiro.ca<mailto:john at tiro.ca>>; mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at<mailto: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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faka.ms%2Fweboutlook&data=02%7C01%7C%7Cb7e16c8c866444adfc6708d8464a6d9e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336632764057984&sdata=jcdRnpuhAplO%2FBwADiRfUBtLFioiacyr2eRT79W2q6s%3D&reserved=0>

________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto:mpeg-otspec-bounces at lists.aau.at>> on behalf of Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>>
Sent: Friday, August 21, 2020 4:32 PM
To: John Hudson <john at tiro.ca<mailto:john at tiro.ca>>; mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at<mailto: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<mailto: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<mailto: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://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7C%7Cb7e16c8c866444adfc6708d8464a6d9e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336632764057984&sdata=zo8H8D3VztnqZ3aBksjl8UdF4%2Bu5li5dNrVCnkM4Ymg%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.
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
https://lists.aau.at/mailman/listinfo/mpeg-otspec<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7Cb7e16c8c866444adfc6708d8464a6d9e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336632764067977&sdata=TiUNfiCRaC9m1V1invAYoR9ubRHDbCMZ5La7MvA6UKk%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200822/a70879b1/attachment-0001.html>