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

Sat Sep 12 00:24:41 CEST 2020

I don’t think you could say “as it used to” in that case since “Selawik New Regular” had never previously been used.

If tried to use a Metafont format file as a Web font and nothing worked, would that be considered a “breaking change”? I don’t think so. It’s just a not-well-supported scenario. If the font in question happened to have a name “Selawik New Regular”, that wouldn’t change anything IMO.

Peter

From: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
Sent: Friday, September 11, 2020 3:17 PM
To: Peter Constable <pgcon6 at msn.com>
Cc: Adam Twardoch (Lists) <list.adam at twardoch.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)

And, if an author decided to use “Selawic New Regular” as a web font and discovered that nothing works as it used to - would that be considered a breaking change?
Thank you,
Vlad

On Sep 11, 2020, at 6:04 PM, Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>> wrote:

My usage of the term “breaking change” is what I am familiar with in software engineering projects: some existing protocol that is redefined so that it no longer works as previously assumed — meaning that existing implementations will have unexpected failures.

If there is an entirely new sfnt version, then whatever is included in that format, I would _not_ consider that a _breaking_ change. It’s a new format that doesn’t provide some transitional compatibility/migration with existing software. In OT1.8x, the ‘glyf’/’gvar’ design allowed for transitional compatibility—the ‘glyf’ table could be read by existing software in a compatible way, but the new functionality wouldn’t be available. CFF2 wasn’t a breaking change; it just didn’t provide any transitional compatibility for existing software.

Now, if a font vendor releases a font, say, “Selawik Regular”, and then publishes a new version of the font that is still called “Selawik Regular” but that uses a new sfnt version/format, I could see that being called a breaking change since documents formatted with “Selawik Regular” would no longer display correctly in existing software if the older font were replace by the new font: it has broken existing documents. But if instead the vendor published a new “Selawik New Regular” font, nothing is broken.

P.

From: Adam Twardoch (Lists) <list.adam at twardoch.com<mailto:list.adam at twardoch.com>>
Sent: Friday, September 11, 2020 2:49 PM
To: Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>>
Cc: Dave Crossland <dcrossland at google.com<mailto:dcrossland at google.com>>; mpeg-otspec <mpeg-otspec at lists.aau.at<mailto: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)

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?

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<mailto: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<mailto: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<mailto:dcrossland at google.com>>

Cc: mpeg-otspec <mpeg-otspec at lists.aau.at<mailto: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.

_______________________________________________
mpeg-otspec mailing list
mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>
https://protect-us.mimecast.com/s/_W_9CgJGKnTlxgjRSNTtca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200911/6cfbed1c/attachment-0001.html>