[MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)

[Levantovsky, Vladimir]

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.
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!

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.

Remember, "In case of conflict, consider users over authors over implementors over specifiers over theoretical purity"!
(https://www.w3.org/TR/html-design-principles/#priority-of-constituencies)

Vlad

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of Renzhi Li
Sent: Sunday, August 30, 2020 6:40 PM
To: Dave Crossland <dcrossland at google.com>
Cc: mpeg-otspec <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values

Well, if we are talking about 2.0, these fields should be removed instead of marked as unused, since 2.0 is no longer compatible with 1.X.

RL
________________________________
From: Dave Crossland <dcrossland at google.com<mailto:dcrossland at google.com>>
Sent: Sunday, August 30, 2020 15:34
To: Renzhi Li <Renzhi.Li at microsoft.com<mailto:Renzhi.Li at microsoft.com>>
Cc: Simon Cozens <simon at simon-cozens.org<mailto:simon at simon-cozens.org>>; mpeg-otspec <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>
Subject: Re: [MPEG-OTSPEC] [EXTERNAL] Proposal to deprecate derived search values

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<mailto: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<mailto:mpeg-otspec-bounces at lists.aau.at>> on behalf of Simon Cozens <simon at simon-cozens.org<mailto:simon at simon-cozens.org>>
Sent: Sunday, August 30, 2020 01:18
To: mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at> <mpeg-otspec at lists.aau.at<mailto: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<mailto: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<https://protect-us.mimecast.com/s/e2iJCQW2m6ikG2mGcPhtAM>
_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
https://lists.aau.at/mailman/listinfo/mpeg-otspec<https://protect-us.mimecast.com/s/e2iJCQW2m6ikG2mGcPhtAM>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/a87756a0/attachment-0001.html>