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

Simon Cozens simon at simon-cozens.org
Sat Sep 12 10:01:40 CEST 2020


On 11/09/2020 22:20, David Singer wrote:
> This is probably a blindingly obvious statement, but a common technique is to differentiate the requirements for readers and creators, e.g. writers must write version 6 as the default, and may write other versions on request; readers must accept version 6, and should accept 3,4,5, and may accept earlier versions (the last doesn’t need saying, of course, people always may do anything above what the specs mandates or recommends).

I keep shouting about this, and it is indeed the approach that I am 
using in creating the "CommonType" documentation.

For format 10 cmap subtables, for example, there is a clear cycle: 
currently font consumers are "discouraged" from creating these 
subtables, but font producers are required to interpret them for the 
current edition; the requirement will be relaxed to "optional" in the 
next edition with an explicit deprecation notice; then the subtable will 
no longer be documented in the edition after that.

A formal consumer/producer deprecation cycle for OFF would, I think, be 
helpful.

S


More information about the mpeg-otspec mailing list