<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cordia New";
panose-1:2 11 3 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:SimSun;
mso-fareast-language:ZH-CN;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Some possible considerations:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">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>_?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">(Of course, itemization itself has a perf cost. But a single shaping engine doesn’t necessarily eliminate any need for itemization.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Just some thoughts…<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="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"?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="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>.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black">Yours,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black">Renzhi<o:p></o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="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>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgooglefonts%2Fnoto-fonts%2Fissues%2F576&data=02%7C01%7C%7C537cece9dd624df55ef408d8460e8b59%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336375565321412&sdata=q3l27%2F4fkQ5G2fEoDQa%2FKVoOIlT7lMjmlHrT19XuKDw%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%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://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7C%7C537cece9dd624df55ef408d8460e8b59%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336375565331407&sdata=G767iZfbzZIH1XpfMx6UvWHPzADZrKat6U%2BO1FJoflQ%3D&reserved=0">
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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7C537cece9dd624df55ef408d8460e8b59%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336375565341400&sdata=9VbwuVlT7eI5zoYwE8Y6EuJc8JM1lDHyT%2FvJkDhRql8%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%7C522f0caf09c44086565608d846085d90%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637336349042908210&sdata=P25aS%2FdwAwWUC7QcYTRErfBSofoFGiU5gMnDPwysGL8%3D&reserved=0</a><o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>