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

Fri Aug 21 23:30:43 CEST 2020

If we choose to go the "Super USE" approach, script tags will become less necessary for shaping, but an script itemizer is still valuable for many functionalities like font fallback. Also we need special scripts for non-standard text layout, like ⟨math⟩/⟨Zmth⟩ for math. Keeping LangSys' organized under script tags isn't a big problem in my opinion.

The performance concern is still there, since there's not only PCs, but also embedded systems. However, we could standardize DWrite's "canBreakShapingAfter" mechanism, which is a great speed-up for text layout. We may need some sort of experts in the area of automatons, regular expressions or rewriting systems to prove the "canBreakShapingAfter algorithm"'s correctness.

Yours,
Renzhi
________________________________
发件人: Peter Constable <pgcon6 at msn.com>
发送时间: 2020年8月21日 13:52
收件人: Renzhi Li <Renzhi.Li at microsoft.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"?

If shaping logic needed for all scripts could be consolidated into a single shaping-process spec, I think that would be a good thing: itemizing strings and shaping in separate script-specific shaping runs adds complexity, so better avoided if there’s no real need. And it would remove one existing obstacle to glyph actions for sequences that cross script-run boundaries.

Some possible considerations:

First, I suspect a factor in MS’s original design was performance: some scripts require processing not required for other scripts, but by routing all text through the same shaping engine the latter scripts incur _some_ penalty. That’s certainly less of an issue in 2020 than it was in 1998. Is it now a non issue _for all implementation environments_?

(Of course, itemization itself has a perf cost. But a single shaping engine doesn’t necessarily eliminate any need for itemization.)

Another possible consideration is interaction with bidi layout. A spec for a unified shaping process will probably need to also spec how bidi-level runs interact with it. E.g., are runs fully resolved before entering the shaping engine with the buffer passed in containing a visual-order character sequence? And if so, what’s the interaction with linebreaking? Or are levels resolved but then LTR runs processed separate from RTL runs; and if so, what implications are there for the shaping engine design?

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? Or would there still be some benefits from having distinct script tags?

Just some thoughts…

Peter

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

It looks like that we could start adding a new set of script tags to route any existing scripts (like Latin) to USE. Or simply route all ISO 15924 script tags (capitalized) to USE? If we had that we could mark all the existing shaping engines as legacy, and their standardization process could be deprioritized.

I really hope that, USE will eventually become a truly universal engine that is driven by some sort of extended UCD data and could process every script of every language.

Yours,

Renzhi

________________________________

发件人: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto:mpeg-otspec-bounces at lists.aau.at>> 代表 John Hudson <john at tiro.ca<mailto:john at tiro.ca>>
发送时间: 2020年8月21日 12:28
收件人: 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>>
主题: [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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgooglefonts%2Fnoto-fonts%2Fissues%2F576&data=02%7C01%7Crenzhi.li%40microsoft.com%7C522f0caf09c44086565608d846085d90%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336349042290911&sdata=D%2BHEgBW34WH7srIxNx4Z2kDaTAhicPxwI1qAhTfNJFg%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgooglefonts%2Fnoto-fonts%2Fissues%2F576&data=02%7C01%7CRenzhi.Li%40microsoft.com%7C8a448c14468544bfdd3b08d8461427ed%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336399672247572&sdata=QqH8%2F7KSMJva0bju2iaL4%2Fjsy20zO2UHVb276GznUqI%3D&reserved=0>

--

John Hudson
Tiro Typeworks Ltd    https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7Crenzhi.li%40microsoft.com%7C522f0caf09c44086565608d846085d90%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336349042908210&sdata=N6PVcUI5H4BlW%2BWyZ0kZKKyv9HqurjtyzZJDU71aK4s%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7CRenzhi.Li%40microsoft.com%7C8a448c14468544bfdd3b08d8461427ed%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336399672257567&sdata=R6Uo%2FYOrFaX6pcgE1LgHgz0aIdGzWyb%2BCJWM%2FJEBNdQ%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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7Crenzhi.li%40microsoft.com%7C522f0caf09c44086565608d846085d90%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336349042908210&sdata=P25aS%2FdwAwWUC7QcYTRErfBSofoFGiU5gMnDPwysGL8%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7CRenzhi.Li%40microsoft.com%7C8a448c14468544bfdd3b08d8461427ed%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336399672257567&sdata=XqnnDFqMMKjfVAfGoxuYEpnj2b6NEbOPZc5JaYuOHUw%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200821/5afd3100/attachment-0001.html>