[MPEG-OTSPEC] Updates to specification

Levantovsky, Vladimir Vladimir.Levantovsky at monotype.com
Thu Aug 13 21:07:34 CEST 2020


Well… (few additional comments)

There is no formal agreement between Microsoft as owner of the OpenType spec and ISO as maintainer of the OFF spec regarding continued synchronisation or even functional compatibility.

Microsoft and all other platform vendors are members of this group, and their participation in this process is crucial to achieving a consensus on a proposal presented for discussion. ISO isn’t just a maintainer of the OFF – the changes are initiated and facilitated by us so, in essence, when it comes to OFF – ISO is _us_. It is less than ideal that we have to maintain two independently published documents, but it also offers a degree of convenience – having the OT spec online sure makes it easier to work with it, and having ISO OFF standard set in stone (PDF, freely available to all via https://standards.iso.org/ittf/PubliclyAvailableStandards/) gives industry the needed assurances that it won’t go anywhere and that implementations are covered by ISO IPR policies.

In the absence of any formal agreement to maintain synchronicity and compatibility between OT and OFF, I have tended to operate on the basis of which process seems stronger in terms of achieving things that will be implemented: Microsoft’s ad hoc consultation with platform vendors (specifically Apple, Adobe, and Google) and some font developers, or ISO/MPEG's AHG process. And, frankly, the former has always seemed stronger: if that group of platform vendors agrees to implement something, e.g. OT variations, it is probably going to get implemented; whereas, adding things to OFF doesn't even guarantee that they’ll make it into the OT spec let alone get implemented.
…
Although I wasn’t philosophically happy with the lack of transparency and openness in the ad hoc OpenType processes, I was practically happy to engage in them when they could get things done.
I’d argue that for as long as we collectively treat this work as a single entity and discuss everything out in the open, with all interested parties being able to freely join the discussion – the _formal_ agreement isn’t necessary (I am not even sure there can be such a thing with ISO having full rights to make changes to their document). We, as a community have vested interest in maintaining the integrity of the technology, and developing it further in a way that facilitates widespread adoption and implementations.

When it comes to new proposals and technical changes, having private discussions to facilitate consensus and implementation plans can obviously be beneficial; however, the lack of transparency introduces clear and present danger that the open discussion process can be circumvented in favor of getting things done quicker. I don’t think I need to remind us all about past instances where hectic decisions made for expedience and convenience had backfired, and unnecessarily complicated the development process. The lack of transparency can also be used to make accusations of impropriety [regardless of whether real or perceived], and should be avoided at all costs. This is why it is so important that we have these discussion here, out in the open, with unmoderated access for any interested party to join.

Vlad


From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of John Hudson
Sent: Thursday, August 13, 2020 1:45 PM
To: mpeg-otspec at lists.aau.at
Subject: Re: [MPEG-OTSPEC] Updates to specification

On 13082020 8:18 am, Simon Cozens wrote:
    Thank you so much for the explanation. That makes a lot of sense. It sounds like: this AHG has an open and formalized process for approving changes, as opposed to the somewhat opaque process that happens when a Github issue is submitted; changes are submitted to ISO through this group, so this is the right place for OFF proposals in the first instance; and MS picks up and integrates accepted proposals made on this list anyway (and probably should not be integrating proposals not discussed here).

Well...

There is no formal agreement between Microsoft as owner of the OpenType spec and ISO as maintainer of the OFF spec regarding continued synchronisation or even functional compatibility. So while, to date, efforts have been made to keep the two specifications in synch — even to the extent of Microsoft incorporating the CBDT, sbix, and SVG  colour font tables, which were first accepted into OFF,  in addition to their own COLR/CPAL format — there is no guarantee that the specifications will remain in synch. Microsoft is not obliged to accept changes proposed and approved through the ISO process, and ISO is not obliged to approve changes that Microsoft make.

Note that Peter’s carefully worded response refers to Microsoft ‘consulting other platform vendors’ and ‘keeping Apple, their original TT partner, in the loop’ — not to making use of the ISO process. To my knowledge the only change to the OpenType specification that was directly proposed, reviewed, and approved through the ISO process was the change to the init, medi, fina, and isol feature descriptions a few years ago, and I had already checked with Microsoft that they agreed with the changes in principle before I submitted the proposals to the OFF AHG. In that case, the ISO process was just a convenient way to do the editorial work on what were, after all, changes only to a registry, not to part of the core OT specification.

In the absence of any formal agreement to maintain synchronicity and compatibility between OT and OFF, I have tended to operate on the basis of which process seems stronger in terms of achieving things that will be implemented: Microsoft’s ad hoc consultation with platform vendors (specifically Apple, Adobe, and Google) and some font developers, or ISO/MPEG's AHG process. And, frankly, the former has always seemed stronger: if that group of platform vendors agrees to implement something, e.g. OT variations, it is probably going to get implemented; whereas, adding things to OFF doesn't even guarantee that they’ll make it into the OT spec let alone get implemented. Let's be clear: the major platform vendors and all the font makers are implementing OpenType; they are not implementing OFF except insofar as the latter happens to be synchronous with OT. [There are, apparently, companies that officially implement the OFF spec, because it provides a way for them to implement OT without appearing to be bound to a proprietary technology, but I've never heard any developer of either software or fonts actually talk about anything other than OpenType.]

So...

OpenType, a proprietary technology owned by Microsoft, is the de facto standard. OFF, as an ISO standard with an open and formalised process for approving changes, is the de jure standard.

Now...

Although I wasn’t philosophically happy with the lack of transparency and openness in the ad hoc OpenType processes, I was practically happy to engage in them when they could get things done. The problem is that after the OT variations release in 2016, those processes ceased to get things done, mostly because Microsoft management took Peter off the OT editorship, and didn’t replace him. This has meant that not only the processes but the spec itself is in limbo. This was really brought home to me after the last face-to-face meetings of the ad hoc working group that Behdad hosted at Facebook last summer, when not one of the things we had discussed over three days — including things we all agreed were critically important, such as a new version of the avar table or similar implementation for virtual/meta axes — got done, either in terms of specification or implementation.

And...

That’s where we still are. My concern as we consider the scope of a proposed text processing and display working group — I think calling it a 'shaping working group' is begging the question with regard to scope —, is that we can easily come up with a lot of excellent ideas and write proposals and other documents, and if we go through the ISO AHG process we can even get these things incorporated into the OFF de jure standard, and there will still be no guarantee that any of them will get implemented or even get incorporated into the OT de facto standard.



JH



--



John Hudson

Tiro Typeworks Ltd    www.tiro.com<https://protect-us.mimecast.com/s/lHvaCwpA5KsG6LW9iq4FqY>

Salish Sea, BC        tiro at tiro.com<mailto:tiro at tiro.com>



NOTE: In the interests of productivity, I am currently

dealing with email on only two days per week, usually

Monday and Thursday unless this schedule is disrupted

by travel. If you need to contact me urgently, please

use some other method of communication. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200813/6cb2f3df/attachment-0001.html>


More information about the mpeg-otspec mailing list