[MPEG-OTSPEC] Updates to specification

Thu Aug 13 20:55:24 CEST 2020

John has made an important point: a standard, even an ISO/IEC standard, isn’t worth much unless it’s actually implemented. My perspective on OT and OFF for several years now has been that a goal for most new technical enhancements should be broad adoption across major platforms.

Many will agree that the colour font formats were a bit of a fiasco that were not particularly helpful for industry at large. Yes, platforms had ways to create emoji fonts, and there were stable and publicly-available specs showing how one could make colour fonts to work on different platforms, if they wanted to. But in general, the type industry is interested in font formats that can work predictably on many end points — many different platforms, applications and devices.

I’ll take a second example from a little earlier (and one that I’m not so proud of): in the mid-2000s, the ISO 639-3 standard was published and being integrated into the IETF language tag specifications (BCP 47), and the latter were being revamped in light of much better understanding across industry of broad and longer term needs in that regard. And at MS, I was among a group evangelizing use of BCP 47 to replace obsolete, proprietary numeric LANGIDs. And as I was working on text display (Uniscribe and shaping engines) at the time, I knew that the ‘name’ table was one of the holdout places where LANGIDs were still required. So, I came up with ‘name’ format 1 as a way to integrate BCP 47 language tags. This came at a time when MS and Adobe were collaborating on design of ‘cmap’ format 14, to handle Unicode variation sequences. So, I included my proposal for ‘name’ format 1 into those discussions. It was reviewed by that working group of engineers from the two companies, and nobody raised objections or major concerns. But—and here’s the rub—nobody committed to or even took a serious interest in implementing it. (On the MS side, the others involved were not from a team especially focused on i18n issues.) So, there’s something that’s in both OT and OFF, but AFAIK it’s never been implemented, and while that remains the case, it’s a complete waste.

The lesson for me in all this has been that, whatever channel is used to introduce changes and, especially, to propose changes for new functionality, it’s critically important to have major platform vendors involved, at a minimum to give review and give a nod that the proposed enhancements would be useful, are well-enough designed and feasible, but even better to have two or more of them indicating a desire to implement the new design in their platforms in the foreseeable future. That was the approach I took for variations, and I think it’s been reasonably successful for industry as a whole.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at> On Behalf Of John Hudson
Sent: Thursday, August 13, 2020 10:45 AM
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://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tiro.com%2F&data=02%7C01%7C%7C27e8c55e556c40a86e3308d83fb0930d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637329374901013912&sdata=cHlkwEkPX8fLBreIlo2%2F0EqEDXkeHHMpm3fowWG99T0%3D&reserved=0>

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/49965fb3/attachment-0001.html>