<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: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=us-ascii">
<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:"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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.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;color:#1F497D">With my chair hat on, I’d like to point out that comments made in passing about 1.X vs. 2.0 aren’t helpful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">We never had any discussions in this group about introducing breaking changes in the future versions of the standard, and it isn’t something that should be taken
 lightly!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Like you said, the legacy code never dies. The integrity of the marketplace we built [by getting OFF/OpenType supported by all major platforms and CE devices]
 should be an absolute priority, and the consensus-based buy-in from all major vendors / implementers would absolutely be needed before any breaking changes are adopted. All implementations that are out in the wild right now (web fonts, digital TV applications,
 etc.) expect the underlying code to be conformant to the spec, and all users and content authors rely on the guarantee of interoperability between different content / font vendors and various platforms – the guarantee that various standards- and W3C Recommendations-compliant
 implementations provide. Breaking this interoperability may have devastating consequences for the community we serve.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Remember, “</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black;background:white">In case of conflict, consider users over authors
 over implementors over specifiers over theoretical purity</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">”!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">(<a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">https://www.w3.org/TR/html-design-principles/#priority-of-constituencies</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Vlad<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><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> Sunday, August 30, 2020 6:40 PM<br>
<b>To:</b> Dave Crossland <dcrossland@google.com><br>
<b>Cc:</b> mpeg-otspec <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> Re: [MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values<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">Well, if we are talking about 2.0, these fields should be
<i>removed</i> instead of <i>marked as unused</i>, since 2.0 is no longer compatible with 1.X.<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">RL<o:p></o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="4" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black"> Dave Crossland <<a href="mailto:dcrossland@google.com">dcrossland@google.com</a>><br>
<b>Sent:</b> Sunday, August 30, 2020 15:34<br>
<b>To:</b> Renzhi Li <<a href="mailto:Renzhi.Li@microsoft.com">Renzhi.Li@microsoft.com</a>><br>
<b>Cc:</b> Simon Cozens <<a href="mailto:simon@simon-cozens.org">simon@simon-cozens.org</a>>; mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at">mpeg-otspec@lists.aau.at</a>><br>
<b>Subject:</b> Re: [MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I think it can be helpful to be more precise about which versions we are talking about. 1.x.x. or 2.x :)<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, Aug 30, 2020, 6:27 PM Renzhi Li <<a href="mailto:Renzhi.Li@microsoft.com">Renzhi.Li@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black">I suspect some Apple code, as well as code in embedded systems, are still relying on such fields because legacy code never dies.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;color:black">A good recommendation should be that, a font
<i>reader</i> should ignore these fields, and a font <i>writer</i> should always provide proper values in case this font is put into legacy systems.<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">RL<o:p></o:p></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="4" width="98%" align="center">
</div>
<div id="x_m_-8422668598250027010divRplyFwdMsg">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</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" target="_blank">mpeg-otspec-bounces@lists.aau.at</a>>
 on behalf of Simon Cozens <<a href="mailto:simon@simon-cozens.org" target="_blank">simon@simon-cozens.org</a>><br>
<b>Sent:</b> Sunday, August 30, 2020 01:18<br>
<b>To:</b> <a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a> <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a>><br>
<b>Subject:</b> [EXTERNAL] [MPEG-OTSPEC] Proposal to deprecate derived search values</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">Peter's email about the Offset Table reminded me of something I've
<br>
wanted to see changed.<br>
<br>
Various parts of OFF - the Offset Table, cmap format 4 and the kern <br>
table - expect the user to supply easily computable transformations of <br>
other fields (searchRange, entrySelector and rangeShift), ostensibly to <br>
optimize the search algorithm. Because this data is derived from another <br>
field, it is redundant information from a storage perspective.<br>
<br>
But the security-conscious programmer should immediately be thinking <br>
"What happens if the font file lies to the shaper about basic <br>
arithmetic?" It turns out that most engines, correctly IMO, ignore the <br>
content of these computer fields and only trust the non-derived fields <br>
(numTables). Uniscribe fails with an error in the presence of a <br>
malicious font file. Of course in order to validate whether the font has <br>
incorrect data, it has to derive the correct data in the first place, <br>
proving the data in the font file redundant.<br>
<br>
I propose that these fields be deprecated for font consumers in the next <br>
OFF version, with a path to becoming marked "unused" for both font <br>
consumers and font producers in a specified future version.<br>
<br>
S<br>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://protect-us.mimecast.com/s/e2iJCQW2m6ikG2mGcPhtAM" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&amp;data=02%7C01%7Crenzhi.li%40microsoft.com%7Ccbf0377e04ea48f0ae0008d84cbd5516%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637343723346615282&amp;sdata=R3atDIm4ABe8cnihRkS5ZUeH6HHWJ4XF8bAK8zr2%2FWs%3D&amp;reserved=0</a><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank">mpeg-otspec@lists.aau.at</a><br>
<a href="https://protect-us.mimecast.com/s/e2iJCQW2m6ikG2mGcPhtAM" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>