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

Sat Aug 22 05:50:13 CEST 2020

I'm feeling like this is a bit like hinting about 10 years ago...

For the most important fonts - well established names, premium retail tier
work, system fonts - then investment into making them work absolutely
everywhere should be possible. Back then this meant hand hinting for
several different windows APIs.

But for new fonts with zero million users, ttfautohint or similar was fine,
because they worked well enough on the newer APIs used by a majority of
users, and the minority of users on older APIs was in terminal decline.

So, existing fonts with indic1/2 tags, that wouldn't work in a hypothetical
system that only supports USE and indic 3 tags, seems like it will be small
too - and can be resolved by the system shipping harfbuzz for such cases,
or the fonts being remastered with all indic 1, 2 and 3 tagged lookups?

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.

On Fri, Aug 21, 2020, 11:35 PM Peter Constable <pgcon6 at msn.com> wrote:

> 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>
> 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
> <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> 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://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
>
>
>
> 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
> <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/20200821/8f09e8d8/attachment-0001.html>