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

[Dave Crossland]

On Fri, Sep 11, 2020, 5:49 PM Adam Twardoch (Lists) <list.adam at twardoch.com>
wrote:

> Well, OK. I guess I misunderstood the notion of “breaking”. Am I right to
> understand that if a new SFNT version (e.g. "OFF2" or \00\02\00\00) gets
> introduced, a lot of old assumptions can be removed?
>

A old assumption to me would be that glyph IDs are limited to 16 bits; I
hear implementations would have a lot of work to deal with 32 bits, having
built up a lot of assumptions that they are 16 bit.

Another old assumption would be that there is a complete separation of
substitution and positioning, that originated in OpenType, and is not made
in ACE.


Of course existing versions of each table identified by a given tag should
> retain their meaning, but older versions of tables could be removed, tables
> could be removed from the spec or even disallowed ("reserved"), and if
> fields or structures are changed/removed in tables that we keep, they
> require a version bump?
>
> A.
>
> On Fri, 11 Sep 2020 at 23:25, Peter Constable <pgcon6 at msn.com> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> That’s not a breaking change. It’s a new feature that requires new
>> software for support. It’s no more breaking than introduction of the colour
>> tables.
>>
>>
>>
>>
>>
>> Changing structures to remove fields or redefining field in structures
>> but without a major table version bump would be a breaking change.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Peter
>>
>>
>>
>>
>>
>>
>>
>> *From:* mpeg-otspec <mpeg-otspec-bounces at lists.aau.at>
>>
>> *On Behalf Of *Adam Twardoch (Lists)
>>
>>
>> *Sent:* Friday, September 11, 2020 1:22 PM
>>
>>
>> *To:* Dave Crossland <dcrossland at google.com>
>>
>>
>> *Cc:* 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/f4ab5c76/attachment.html>