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

[Adam Twardoch (Lists)]

Right now am implementer of OT 1.8 has to implement support for all six
versions of the OS/2 table. OFF2 could get rid of that burden.

The implementer could of course re-use their code if exists to support all
versions but only allow the latest in OFF2. But at some point a dev could
make a faster code path for OFF2 and only run a slower legacy code path for
OFF1.

If we do cubic glyf and drop CFF(2) from OFF2 (I know, I know), that'd
allow for the new code be much leaner.

And in some controlled environments they could only deploy the leaner OFF2
code, which could also be a lot safer (speaking as a person who discovered
a CFF vulnerability in Win 7 that prompted MS to issue 3 "most critical"
patches for all their OSes).

Or at least OFF2 could drop CFF[1] and only keep CFF2.

A.

On Fri, 11 Sep 2020 at 23:02, Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Agree. I am not at all against new technology replacing the old stuff.
> Using your own example, I’ve been a loud proponent of WOFF2, even though it
> was a clear
>
> break from WOFF1 – the benefits of WOFF2 to users and authors were clear
> and undisputed evidence on which the breaking change was introduced.
>
>
>
>
>
>
> Like you said, different solutions can peacefully co-exist and the new
> OFF2 can be devised in such a way would minimize adverse impact of breaking
> changes on
>
> the existing marketplace. My main point is that doing so requires
> discussions and considerations of different points of view from all major
> implementers and font vendors to form a consensus.
>
>
>
>
>
> Vlad
>
>
>
>
>
>
>
>
> *From:* Adam Twardoch (Lists) <list.adam at twardoch.com>
>
>
>
>
> *Sent:* Friday, September 11, 2020 4:22 PM
>
>
> *To:* Dave Crossland <dcrossland at google.com>
>
>
> *Cc:* Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>;
> mpeg-otspec <mpeg-otspec at lists.aau.at>
>
>
> *Subject:* Re: [MPEG-OTSPEC] Introducing breaking changes into the spec
> (was: RE: [EXTERNAL] Proposal to deprecate derived search values)
>
>
>
>
>
>
>
> Hello Vlad,
>
>
>
>
>
>
>
>
>
>
>
> OpenType 1.8 introduced a major breaking change: OpenType fonts in which
> the only source for glyph rendering is the 'CFF2' table. Those fonts
> (variable or not) conform with the OT 1.8 spec but older implementations
> can’t do anything about
>
> them.
>
>
>
>
>
>
>
>
>
>
>
> I believe OFF has followed suit, therefore introducing a breaking change
> to the ISO standard.
>
>
>
>
>
>
>
>
>
>
>
>
>
> There is nothing in the world that speaks against OFF 1.x and OFF 2.x
> co-existing. These versions could be treated as “levels“. H.264 is one
> codec in MPEG and H.265 is another, which older implementations know
> nothing about.
>
>
>
>
>
>
>
>
>
>
>
>
>
> The OFF can be devised in such a way that both the 1.x “level“ and the new
> 2.x “level” co-exist in the standard. There should be a clear distinction
> between these levels, and the last known 1.x rendition (equivalent to the
> last OT 1.8.x
>
> or 1.9.x) should stay in the OFF standard “forever”.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Implementers can be free to then make their code work with OFF1 only, or
> OFF2 only, or both. Font makers will also be free to release their fonts as
> OFF2 and also as OFF1, or both.
>
>
>
>
>
>
>
>
>
>
>
>
>
> WOFF[1] and WOFF2 are technically completely different, and there are
> implementations that support both or only one. WOFF2 was a complete
> breaking charge towards WOFF. I don't think OFF2 wants to go that far (as
> in, abandoning the SFNT
>
> container and going with something completely different), but I’d not
> exclude even that possibility.
>
>
>
>
>
>
>
>
>
>
>
>
>
> When the Variable OT fonts were introduced, or became clear that for many
> scenarios, an intermediate layer of software needs to be introduced (e.g.
> for embedding into the print stream). Effectively, a OT 1.8 > OT pre-1.8
> conversion step,
>
> an “unbreaker” for those de-facto breaking changes that OT 1.8 brought.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Many software vendors are aware of this step being need. Since that
> filtering/conversion step is being added everywhere, there should be no
> problem of extending that step in future, so it can also convert OFF2 into
> OT pre-1.8 or OFF1.
>
>
>
>
>
>
>
>
>
>
>
>
>
> A.
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/5fac3544/attachment-0001.html>