Skip to content

Instantly share code, notes, and snippets.

@behdad
Created August 18, 2020 17:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save behdad/d08f958f8a5e2cb6badf6e32598427df to your computer and use it in GitHub Desktop.
Save behdad/d08f958f8a5e2cb6badf6e32598427df to your computer and use it in GitHub Desktop.
2016-02-13 Peter Constable opentype-layout smoking-gun message
Vlad:
I don’t see any attachment, and I have no idea what is in this amendment other than the little I glean from glancing over this thread.
Actually, I have no idea what’s been going into OFF for some time, though granted, I was out of this space for a while and only came back into it in the past year or so. However, I’ve been working on the DirectWrite platform in Windows during this time, and can say I’m not aware of anything that has gone into DirectWrite in that time that pertains to recent amendments to OFF except, perhaps, things related to USE. (DWrite has been picking up our shaping library from Andrew’s team.)
My concern is with changes going into OFF without knowing what the status is of platforms that actually implement support for OpenType fonts. And quite frankly, I’m SHOCKED to see that there are changes to the OS/2 table being rushed into OFF that Microsoft has not review.
I don’t see any indication of discussion in this list of a new OS/2 version with a usTypoWeightClass field. This mail thread is the first I’ve known of it. Searching in the OpenType list (which I don’t consider the best forum for driving consensus among implementers on OpenType changes), I see that this was first mentioned on 2015–11–19 — not even three months ago. I haven’t reviewed this at all so am not biased for or against the idea. However, in principle…
!!! Rushing something like this into an OFF amendment without adequate review by platform vendors is a BAD IDEA. !!!
It used to be that Adobe would come to Microsoft with an idea for a new OTL feature or other OpenType enhancement, or vice versa, and we could agree on things that made sense for implementations. When I was working in this space previously, Microsoft and Adobe collaborated to define cmap format 14 to support variation sequences, and support for that was implemented in our platforms in parallel with updates to the OpenType spec, all fairly quickly. That was a good way of working that was conducive to interoperable fonts.
But now, Vlad, you are collecting ideas from people, evidently without consensus across platform vendors who are the ones that create text layout and rendering implementations, and driving those into OFF. This OS/2 addition is one example that Microsoft, at least, has not reviewed, and without review we can’t comment on whether we think these changes would be appropriate to incorporate in implementations. This is not conducive to interoperability.
We already have a small fiasco with colour formats, with four different formats implemented by different vendors, including two different colour bitmap formats. Unless there are good benefits to each format that would motivate platforms to implement support for all, that is a _hindrance_ to interoperability, not a help. We should not continue this kind of precedent.
The opentype-layout list was created for the specific purpose of collaboration among platform implementers who have explicitly agreed to collaborate on specific refinements to OpenType. Floating ideas for consideration is fine, but unilateral proposals getting absorbed into OFF (to whatever extent that might have happened) was certainly not the intent. I would make the point even more strongly for the OpenType list: it has had so much noise over the years that it has become a hindrance to collaboration among platform vendors, which was one of the main motivations for us to start this separate list. Hence, I would even more strongly say that taking a proposal floated on the OpenType list and absorbing that into OFF without explicit review from platform vendors is a bad idea.
I’m not saying that all of the vendors need to weigh in on every change. If there are refinements to the CFF spec, my company is willing to trust Adobe’s judgment on those things so long as backwards compatibility is maintained (old fonts continue to work in new implementations, and minor-version refinements to existing fonts allow them to work on old implementations). But my company certainly has a large stake in changes to things like the OS/2 table or OpenType Layout, which we created.
I know there are people, such as Martin and John, who have been concerned that suggestions that get floated fall on deaf ears. That’s a valid concern. But driving changes into OFF without getting consensus across platform vendors is not the best way to obtain the changes you seek.
I’m voicing general concerns that I’ve had for a while. I’m not certain what needs to change as general practice. I get very worried by indicators that changes are going into OFF without corresponding review among platform vendors that have a significant stake in things. In general, I think Adobe, Apple, Google and Microsoft should be given opportunity to review proposed changes. And I would be much more confident in a process that involved changes first going into the OpenType spec and, from there, into OFF. After all, that is how OFF originated. Moreover, it would be a better way to ensure that Microsoft and Adobe, at least, have both reviewed those changes, and Microsoft has a long history of keeping Apple in the loop on OpenType changes, with similar interactions with Google in recent years since they have started having more of a role in this space.
But on one specific, I really don’t like the idea of OS/2 changes getting rushed into OFF and request that you NOT include this into this amendment that is going into final ballot. Please confirm that you will postpone this for consideration in a future amendment, pending further review.
Peter
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment