<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 11, 2020, 5:49 PM Adam Twardoch (Lists) <<a href="mailto:list.adam@twardoch.com">list.adam@twardoch.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">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? </div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">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? </div><div dir="auto"><br></div><div dir="auto">A.</div><div dir="auto"><br></div><div dir="auto">On Fri, 11 Sep 2020 at 23:25, Peter Constable <<a href="mailto:pgcon6@msn.com" target="_blank" rel="noreferrer">pgcon6@msn.com</a>> wrote:<br></div></div></div><div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br><br><br><br><br><br><br><br><br><br><br><br><div lang="EN-US" link="#0563C1" vlink="#954F72"><br><br><div><br><br><p class="MsoNormal">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.<u></u><u></u></p><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br><p class="MsoNormal">Changing structures to remove fields or redefining field in structures but without a major table version bump would be a breaking change.</p></div></div><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br><p class="MsoNormal">Peter<u></u><u></u></p><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br><div style="border-style:solid none none;border-top-width:1pt;padding:3pt 0in 0in;border-top-color:rgb(225,225,225)"><br><br><p class="MsoNormal"><b>From:</b> mpeg-otspec <<a href="mailto:mpeg-otspec-bounces@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec-bounces@lists.aau.at</a>> <b><br><br>On Behalf Of </b>Adam Twardoch (Lists)<br><br><br><b>Sent:</b> Friday, September 11, 2020 1:22 PM<br><br><br><b>To:</b> Dave Crossland <<a href="mailto:dcrossland@google.com" target="_blank" rel="noreferrer">dcrossland@google.com</a>><br><br><br><b>Cc:</b> mpeg-otspec <<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec@lists.aau.at</a>><br><br><br><b>Subject:</b> Re: [MPEG-OTSPEC] Introducing breaking changes into the spec (was: RE: [EXTERNAL] Proposal to deprecate derived search values)<u></u><u></u></p><br><br></div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br><div><br><br><p class="MsoNormal">Hello Vlad,<u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><p class="MsoNormal">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<br><br> them. <u></u><u></u></p><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">I believe OFF has followed suit, therefore introducing a breaking change to the ISO standard. <u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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.<u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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<br><br> or 1.9.x) should stay in the OFF standard “forever”. <u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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. <u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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<br><br> container and going with something completely different), but I’d not exclude even that possibility. <u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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,<br><br> an “unbreaker” for those de-facto breaking changes that OT 1.8 brought.<u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">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. <u></u><u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal"><u></u> <u></u></p><br><br></div><br><br><div><br><br><p class="MsoNormal">A.<u></u><u></u></p><br><br></div><br><br></div><br><br></div><br><br><br><br></blockquote></div></div><br><br></div><br><br></div>
</blockquote></div></div></div>