<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">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.</span><br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">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
<i>prove</i> the "canBreakShapingAfter algorithm"'s correctness.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Yours,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Renzhi</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>发件人:</b> Peter Constable <pgcon6@msn.com><br>
<b>发送时间:</b> 2020年8月21日 13:52<br>
<b>收件人:</b> Renzhi Li <Renzhi.Li@microsoft.com>; John Hudson <john@tiro.ca>; mpeg-otspec@lists.aau.at <mpeg-otspec@lists.aau.at><br>
<b>主题:</b> RE: [MPEG-OTSPEC] 回复: [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?</font>
<div> </div>
</div>
<style>
<!--
@font-face
{font-family:SimSun}
@font-face
{font-family:"Cordia New"}
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{}
p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:SimSun}
a:link, span.x_MsoHyperlink
{color:blue;
text-decoration:underline}
.x_MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:1.0in 1.0in 1.0in 1.0in}
div.x_WordSection1
{}
-->
</style>
<div lang="EN-US" link="blue" vlink="purple">
<div class="x_WordSection1">
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">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.</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">Some possible considerations:</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">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 _<i>some</i>_ penalty. That’s certainly less of an issue in 2020 than it was in 1998. Is it now a non issue _<i>for all implementation environments</i>_?</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">(Of course, itemization itself has a perf cost. But a single shaping engine doesn’t necessarily eliminate any need for itemization.)</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">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?</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">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 _<i>set</i>_ of script tags, would just _<i>one</i>_ new “script” tag suffice? Or would there still be some benefits from having distinct script
tags?</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">Just some thoughts…<br>
<br>
</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">Peter</span></p>
<p class="x_MsoNormal"><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> </span></p>
<div>
<div style="border:none; border-top:solid #E1E1E1 1.0pt; padding:3.0pt 0in 0in 0in">
<p class="x_MsoNormal"><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif"> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at>
<b>On Behalf Of </b>Renzhi Li<br>
<b>Sent:</b> Friday, August 21, 2020 12:42 PM<br>
<b>To:</b> John Hudson <john@tiro.ca>; mpeg-otspec@lists.aau.at<br>
<b>Subject:</b> [MPEG-OTSPEC] </span><span lang="ZH-CN" style="font-size:11.0pt">回复</span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif">: [EXTERNAL] Re: Shaping behavior standardization: multi-engine or "Super USE"?</span></p>
</div>
</div>
<p class="x_MsoNormal"> </p>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black">It looks like that we could start adding a new set of script tags to route
<i>any</i> 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.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black">I really hope that, USE will eventually become a
<i>truly universal</i> engine that is driven by some sort of extended UCD data and could process
<i>every script</i> of <i>every language</i>.</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black"> </span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black">Yours,</span></p>
</div>
<div>
<p class="x_MsoNormal"><span style="font-family:"Calibri",sans-serif; color:black">Renzhi</span></p>
</div>
<div class="x_MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="x_divRplyFwdMsg">
<p class="x_MsoNormal"><b><span lang="ZH-CN" style="font-size:11.0pt; color:black">发件人</span></b><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">
mpeg-otspec <<a href="mailto:mpeg-otspec-bounces@lists.aau.at">mpeg-otspec-bounces@lists.aau.at</a>>
</span><span lang="ZH-CN" style="font-size:11.0pt; color:black">代表</span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black"> John Hudson <<a href="mailto:john@tiro.ca">john@tiro.ca</a>><br>
</span><b><span lang="ZH-CN" style="font-size:11.0pt; color:black">发送时间</span></b><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black"> 2020</span><span lang="ZH-CN" style="font-size:11.0pt; color:black">年</span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">8</span><span lang="ZH-CN" style="font-size:11.0pt; color:black">月</span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">21</span><span lang="ZH-CN" style="font-size:11.0pt; color:black">日</span><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">
12:28<br>
</span><b><span lang="ZH-CN" style="font-size:11.0pt; color:black">收件人</span></b><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">
<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a> <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>><br>
</span><b><span lang="ZH-CN" style="font-size:11.0pt; color:black">主题</span></b><b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black">:</span></b><span style="font-size:11.0pt; font-family:"Calibri",sans-serif; color:black"> [EXTERNAL]
Re: [MPEG-OTSPEC] Shaping behavior standardization: multi-engine or "Super USE"?</span>
</p>
<div>
<p class="x_MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="x_MsoNormal"><span style="font-size:11.0pt">On 21082020 12:13 pm, Renzhi Li wrote:<br>
> Therefore, for the shaping behavior standardization, should we <br>
> standardize all the existing engines (focus on the "status quo"), or <br>
> work on USE extension to use one single engine for every script?<br>
<br>
Both.<br>
<br>
We do need to ensure that the existing engines provide consistent <br>
results for existing fonts built to those specs, even if we also provide <br>
mechanisms to pass scripts to USE instead.<br>
<br>
The USE layout model is both general and particular: it requires fonts <br>
for scripts with complex shaping requirements for correct text display <br>
to be made in a very particular ways, which are not compatible with the <br>
methods used in fonts for existing shaping engines. So passing any <br>
script that currently goes to a dedicated engine through USE is going to <br>
require new script tags (or another special convention, e.g. a generic <br>
script tag. Even simple scripts might involve some different methods <br>
when being passed through USE, and would need to be considered cautiously.<br>
<br>
[With regard to the latter, there was recently a discussion on the Noto <br>
repo regarding whether scripts with very simple layout requirements <br>
should be passed to USE*. My inclination is yes, they should, and that <br>
any newly supported script should be passed through USE regardless of <br>
the simplicity or complexity of shaping requirements. It would be <br>
helpful to know the position of the USE implementers on this.]<br>
<br>
JH<br>
<br>
<br>
* <a href="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" originalsrc="https://github.com/googlefonts/noto-fonts/issues/576" shash="oc45xhtYSM7r9BBdjJEXTW/mJ5VIx1ierzHDjaeWsqRXzSmH8b+B0iwV4vy5YxsqPTwrO0ReKbmofTAt8eHFwCn/UnNZnHS1tX/Uo8vivq8AohT3pysMu04Ncc4KDbooSFQyfx0i2yS+UOI06Z1EWG5H7/o02KRWzhO4329iJ9A=">
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</a><br>
<br>
<br>
-- <br>
<br>
John Hudson<br>
Tiro Typeworks Ltd <a href="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" originalsrc="http://www.tiro.com/" shash="eN5cisAvDci8xN26tJZbNg70hXno2TPKFxlIQs0WZbJpvlq1RCBQFJfXJuL6YtOG4sjFmXgiWFAVvdzI+V//UsPa/nymaYHy8aGJzr5SA3S9GRcp2kxNM2tt2flRrEDuN+eBXnAvxPubIfQivTc35vb4Yf5k1MjnRTdrtV4db3c=">
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</a><br>
Salish Sea, BC <a href="mailto:tiro@tiro.com">tiro@tiro.com</a><br>
<br>
NOTE: In the interests of productivity, I am currently<br>
dealing with email on only two days per week, usually<br>
Monday and Thursday unless this schedule is disrupted<br>
by travel. If you need to contact me urgently, please<br>
use some other method of communication. Thank you.<br>
<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a><br>
<a href="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" originalsrc="https://lists.aau.at/mailman/listinfo/mpeg-otspec" shash="jyskVvPw7tv/PIciBRKDX18P9FMON5oR4ehDt5QVsrU3jeyxyXnSu+JUn02rvZl6oUaC9lIjdJnFyr5n1siNd/D4Or6mOYlUNjbbvMSxvws6aUsKKVTCS52WSXvGiruPZUZTIjFki3MQ44/pMzbVt9/xTvqpSAqM31G4+Y+IcWs=">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</a></span></p>
</div>
</div>
</div>
</div>
</body>
</html>