[MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values

Renzhi Li Renzhi.Li at microsoft.com
Mon Aug 31 00:27:10 CEST 2020


I suspect some Apple code, as well as code in embedded systems, are still relying on such fields because legacy code never dies.
A good recommendation should be that, a font reader should ignore these fields, and a font writer should always provide proper values in case this font is put into legacy systems.

RL
________________________________
From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> on behalf of Simon Cozens <simon at simon-cozens.org>
Sent: Sunday, August 30, 2020 01:18
To: mpeg-otspec at lists.aau.at <mpeg-otspec at lists.aau.at>
Subject: [EXTERNAL] [MPEG-OTSPEC] Proposal to deprecate derived search values

Peter's email about the Offset Table reminded me of something I've
wanted to see changed.

Various parts of OFF - the Offset Table, cmap format 4 and the kern
table - expect the user to supply easily computable transformations of
other fields (searchRange, entrySelector and rangeShift), ostensibly to
optimize the search algorithm. Because this data is derived from another
field, it is redundant information from a storage perspective.

But the security-conscious programmer should immediately be thinking
"What happens if the font file lies to the shaper about basic
arithmetic?" It turns out that most engines, correctly IMO, ignore the
content of these computer fields and only trust the non-derived fields
(numTables). Uniscribe fails with an error in the presence of a
malicious font file. Of course in order to validate whether the font has
incorrect data, it has to derive the correct data in the first place,
proving the data in the font file redundant.

I propose that these fields be deprecated for font consumers in the next
OFF version, with a path to becoming marked "unused" for both font
consumers and font producers in a specified future version.

S
_______________________________________________
mpeg-otspec mailing list
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%7Ccbf0377e04ea48f0ae0008d84cbd5516%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637343723346615282&sdata=R3atDIm4ABe8cnihRkS5ZUeH6HHWJ4XF8bAK8zr2%2FWs%3D&reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200830/b8d82b33/attachment.html>


More information about the mpeg-otspec mailing list