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

[Dave Crossland]

I think it can be helpful to be more precise about which versions we are
talking about. 1.x.x. or 2.x :)

On Sun, Aug 30, 2020, 6:27 PM Renzhi Li <Renzhi.Li at microsoft.com> wrote:

> 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
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200830/bc52dc39/attachment.html>