<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<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);">
I suspect some Apple code, as well as code in embedded systems, are still relying on such fields because legacy code never dies.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</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);">
RL</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>From:</b> mpeg-otspec <mpeg-otspec-bounces@lists.aau.at> on behalf of Simon Cozens <simon@simon-cozens.org><br>
<b>Sent:</b> Sunday, August 30, 2020 01:18<br>
<b>To:</b> mpeg-otspec@lists.aau.at <mpeg-otspec@lists.aau.at><br>
<b>Subject:</b> [EXTERNAL] [MPEG-OTSPEC] Proposal to deprecate derived search values</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">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>
mpeg-otspec@lists.aau.at<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%7Ccbf0377e04ea48f0ae0008d84cbd5516%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637343723346615282&sdata=R3atDIm4ABe8cnihRkS5ZUeH6HHWJ4XF8bAK8zr2%2FWs%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%7Ccbf0377e04ea48f0ae0008d84cbd5516%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637343723346615282&sdata=R3atDIm4ABe8cnihRkS5ZUeH6HHWJ4XF8bAK8zr2%2FWs%3D&reserved=0</a><br>
</div>
</span></font></div>
</body>
</html>