[Opentype-layout] DRAFT 1.1 : Proposal to redefine OpenType Layout joining features
Levantovsky, Vladimir
vladimir.levantovsky at monotype.com
Sun Feb 14 08:08:06 CET 2016
Peter,
The reason you didn’t see an attachment is because the <opentype-layout> list (unlike the <mpeg-OTspec> list) doesn’t allow them.
The success of this list, or any other list, is primary dependent on two things - what the list server and moderator allows you to do, and the active participation of the list members. As far as <mpeg-OTspec> list is concerned, it offers the following features that I found to be far superior to any other lists we currently use:
- unrestricted participation by any interested party or individual member;
- unrestricted cross-list email exchange (i.e. messages can be exchanges with multiple lists copied on the same email that won’t be stripped by the list server, unlike e.g. <opentype> list that does restrict other lists);
- unlimited email relays *with unrestricted attachments* (both <opentype> and <opentype-layout> lists don’t allow attachments);
- web archive of all messages sent to the list (with attachments available for download, see: https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages);
- web-based management of list membership (both at individual level and group level: https://groups.yahoo.com/neo/groups/mpeg-OTspec/members/all);
- web-based file storage capabilities and other features (https://groups.yahoo.com/neo/groups/mpeg-OTspec/files).
When it comes to you not being able to see the communication and messages that were exchanged on the mpeg-OTspec list, I am really concerned and puzzled by it. You _are_ a member of the mpeg-OTspec group (you can see a full list of all subscribed members here: https://groups.yahoo.com/neo/groups/mpeg-OTspec/members/all) and, as you can see from the web archive of all messages exchanged on the list (https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages) other members of the list are able to receive and respond to the messages sent to the email list, including your colleagues (see e.g. a message from Greg Hitchcock on Aug. 28, 2015: https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1348).
I would also like to touch on the subject of the amendment process. Every time a change or correction has been proposed - there have been active discussions and ample time given for any interested member to respond. There has never been a single change that would make it into an amendment without a consensus from the group, and when there are no objections raised to a pending proposal - silence is treated as approval. Nothing is ever rushed - for example, the items that are currently considered for a new amendment have been posted to the list for comments as early as Nov. 2015, see:
https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1366 and
https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1363
Again, it is my assumption that everybody who is subscribed to the list can see the email exchange, and my responsibility as an ad-hoc group chair is to provide ample time for every interested member to respond and comment on a proposal or to object to it. When it comes to new features or proposals such as the most recent usTypoWeightClass field - I DID NOT include it in the proposed draft and instead raised the question asking the group to validate and comment on this particular issue. Again, it is my goal to ensure that all the decisions we make are based on the consensus of the group, and I'd really appreciate your active participation in this important work. I do not believe that there have been even a single case when a spec change has been made without consulting with all interested parties - no changes are EVER RUSHED but I consider three months period to be an ample warning time for anyone to respond to the email, even if only to say that more time is needed to make a decision or review a proposed change. IMHO, a simple email reply is a far more effective communication tool than using CAPS followed by multiple exclamation signs !!!
I am looking forward to your active participation in the future discussions and would like to urge you to check your spam filter settings to make sure that the emails from the mpeg-OTspec list aren’t inadvertently held or blocked from your inbox.
Peter wrote:
> 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.
I am genuinely stunned by your remarks regarding the color support. First of all (as a technical nit), I am aware of only one color bitmap format supported and implemented in the spec. As far as color support capabilities are concerned, I believe this was a truly open industry effort when all interested parties came together to develop a solution that can accommodate the needs of every platform in existence, and every effort was made to ensure that tools defined in the standard (e.g. 'CPAL' table) can be shared among two defined outline formats (layered TrueType outlines and SVG). The ISO meeting that took place in January 2014 was *the only one* where ALL interested parties were represented by their delegates - folks from Google, Adobe, W3C and Microsoft were all present there in person and the results of this effort was the exact opposite of what I'd consider a fiasco. And to be fair, the technical solution we ended up with is the one that offers clear advantages on every level - color bitmaps offer easy solution for low-end platforms, layered colored outlines provide scalable solution for Emoji and SVG outlines offer rich expressive capabilities (such as color and opacity gradients, animation, etc.) that will truly revolutionize color fonts of the future - all properly integrated with the rest of features defined by the standard. I'd consider it our greatest success of the recent times, definitely not a fiasco!
> 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.
The reality of ISO process is that *all* interested parties are given equal opportunities to propose, discuss and object to new features and everybody is treated equally and with respect. Yes, every possible effort is made to make sure that all interested parties have a voice, and I personally solicit opinions of every concerned member of the group but I can only hope that the emails exchanged on the list are read by you and other members - when I solicit comments and inform the group of the looming deadline to respond - there is a limit to what can be done past the deadline, especially when it is explicitly stated that silence is treated as approval. Yes, collaboration is what will ultimately produce the best results and every participant of the ISO process is given EQUAL OPPORUNITIES to participate.
> 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.
As a group chair, I treat every contributing member of the group EQUALLY. When a proposal is submitted by the experts in the field, my responsibility is to make sure that the proposal has been well founded and that sufficient time for discussing the proposal was offered. Quite often, a proposal is made *after* the discussion has taken place and I still insist that there is an ample time available for comments, proactively reaching out to solicit comments from those who are key contributors to platform implementations (as Greg's email to the list clearly indicates). I find your accusations to be absolutely unfounded, especially considering your own admission that you have not followed the group activities for more than a year.
> 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.
I absolutely agree, this is exactly why I DID NOT include proposed OS/2 addition in the recent draft and instead asked for members of the group to comment on it. If anything, this particular case is the example that no decisions are taken lightly and no proposal will simply make it through without being given a proper consideration. I value your opinion and am looking forward to you active and informed participation in the group activities.
> 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.
My understanding is that <opentype-layout> list was created under auspices of the Unicode Consortium to allow language and layout experts conduct the discussions that are focused on very specific topics, it wasn't intended to become a substitute for any other industry forum. The results of these discussions being brought up to the attention of the mpeg-OTspec list as a proposal is exactly what needs to happen to make sure the proposal will at some point in the future be absorbed into OFF / OpenType spec. So far, the only such proposal that was communicated from the <opentype-layout> list to <mpeg-OTspec> list was John Hudson's proposed changes for <init>, <medi>, <fina> and <isol> feature descriptions - I have no reason to second-guess the expert opinion of the list members when it comes to specific implementation details of a set of features that are language- and script-specific. Your allegations of "unilateral proposals getting absorbed into OFF" are absolutely unfounded and ill-informed.
> 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.
Again, I agree with you and I also would like to add that there have never been a single proposal floated on the OpenType list that was absorbed into OFF without proper discussion happening on the <mpeg-OTspec> list, which so far has been the only forum where any OFF changes have been discussed following a rigorous process with proper due diligence given for any proposed spec changes.
> 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.
Peter, all I can say is that while I understand and share your concerns I believe they are absolutely unfounded and not warranted by any actions the members of the ad-hoc group have taken in the past. No changes have ever gone into OFF without being reviewed by major stakeholders.
> 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.
Yes, OFF originated as Microsoft and Adobe contribution to the ISO. However, as the established ISO standard, it is now subject to ISO process and policies that, among others, require equal opportunities being given to every participant - experts from Adobe, Apple, Google, Microsoft, Monotype and many individual experts are all members of the ISO ad-hoc group (as you can see from the group membership list) are represented there. You are free to innovate and experiment and introduce new ideas in your platform implementation but new ideas can also be contributed by people who have no association with Microsoft. This is why having an open, industry-wide forum that is dedicated to discussing new proposals and, ultimately, after proper review and consideration is given, making them part of the ISO standard is so important! From day one of OFF existence to this day - every change that was introduced in OFF has been made in sync with the OpenType specification (and this is a very good thing IMO). I know you are very well aware of the ISO process and there is no need to remind you that it is the ISO who has a complete control over the OFF standard - we as the members of the group can influence all decisions and my ultimate goal is to ensure that these decisions are made by consensus! Please contribute, feel free to disagree or object to any proposal that you may find not properly reviewed or not ready for inclusion in the spec, but please do so as involved (and informed) group member.
> 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.
Again, just to reiterate the obvious - the proposed OS/2 changes were only offered for discussion by the ad-hoc group members. The document I recently prepared and circulated for AHG review (you can see it in AHG web archive: https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1371) lists items that would be proposed for a NEW amendment (that doesn’t exist yet)to be created in the future, and this document DOES NOT INCLUDE proposed OS/2 change (other than clarification of the value range of existing usWeightClass field). There is no reason to be concerned by the changes that are not even included in the proposed draft. The only real reason for concern here is to make sure that your email client is not robbing you of the opportunity to be an active contributor to the AHG work and be able to voice your opinion on every proposal that is circulated and discussed on the group list.
And, as far as the choice of email lists are concerned, I believe the mpeg-OTspec list offers a spectacular choice of features (that I outlined in the beginning of this email) but if you believe that there is another worthy alternative that is far superior to what we have and ought to be considered as a new industry-wide forum, I would be more than happy to consider moving the ISO ad-hoc group communications to a new medium. The reality of today is that none of the lists we are all subscribed to offer the same set of rich features that Yahoo Group does. Active participation of all interested parties is all it takes to make it as good of the industry forum as it can possibly be. And, when it comes to list / group status - this is OUR forum where every member can be heard, every voice counted and where people can join the discussions and speak up without list moderator's approval.
Thank you,
Vladimir
-----Original Message-----
From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Saturday, February 13, 2016 1:52 PM
To: Levantovsky, Vladimir
Cc: opentype-layout at unicode.org
Subject: RE: [Opentype-layout] DRAFT 1.1 : Proposal to redefine OpenType Layout joining features
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
-----Original Message-----
From: Opentype-layout [mailto:opentype-layout-bounces at unicode.org] On Behalf Of Levantovsky, Vladimir
Sent: Tuesday, February 9, 2016 2:31 PM
To: Ken Lunde <lunde at adobe.com>
Cc: opentype-layout at unicode.org
Subject: Re: [Opentype-layout] DRAFT 1.1 : Proposal to redefine OpenType Layout joining features
Hi Ken,
These changes are the parts of the amendment (attached) that is currently under final ballot.
Thank you,
Vlad
-----Original Message-----
From: Ken Lunde [mailto:lunde at adobe.com]
Sent: Tuesday, February 09, 2016 4:18 PM
To: Levantovsky, Vladimir
Cc: John Hudson; Bob Hallissy; opentype-layout at unicode.org
Subject: Re: [Opentype-layout] DRAFT 1.1 : Proposal to redefine OpenType Layout joining features
Vladimir,
Is my suggested changes to the 'vert' feature plus the new 'vrtr' feature included? I know that those slipped between the proverbial cracks before, and cannot remember where they stand. These are not reflected in the 2015 edition, which is why I ask.
Best...
-- Ken
> On Feb 8, 2016, at 11:27 AM, Levantovsky, Vladimir <vladimir.levantovsky at monotype.com> wrote:
>
> Dear John,
>
> On Sunday, February 07, 2016 11:18 PM you wrote:
>
>> I'll wait until I hear back from Vlad regarding whether the proposal
>> will be considered for the current ballot. If so, I'll forward your
>> mail as a comment. In not, I'll look at incorporating your suggestion in a revised submission.
>
> The current ballot is the final approval ballot for an amendment related to font collection items and I am afraid that it may not be possible to introduce new changes via ballot comments at this time. I suggest that we (the AHG) should initiate the new amendment to implement all the recent proposed updates related to advanced layout features - we'll have your proposal for <isol>, <init>, <medi>, and <fina> features combined with suggested deprecation of <hngl>, as well as changes for <halt> and <vhal> proposed earlier by Ken Lunde and clarification for OS/2.usWeightClass and the addition of the OS/2.usTypoWeightClass proposed by Sairus combined in a single new amendment. The good news is that the timing for this new amendment is perfect - we can have it finalized and published for ISO ballot by the end of February.
>
> Thank you,
> Vlad
>
>
> -----Original Message-----
> From: Opentype-layout [mailto:opentype-layout-bounces at unicode.org] On
> Behalf Of John Hudson
> Sent: Sunday, February 07, 2016 11:18 PM
> To: Bob Hallissy; opentype-layout at unicode.org
> Subject: Re: [Opentype-layout] DRAFT 1.1 : Proposal to redefine
> OpenType Layout joining features
>
> On 06/02/16 21:23, Bob Hallissy wrote:
>
>> However I'm slightly concerned about the wording of the new examples.
>> E.g., in the case of fina feature, the proposal currently says:
>>> Example: In an Arabic script font, the default form of the letter و
>>> is replaced with the right-joining final form و when following a
>>> left-joining character.
>> If I didn't know better, I'd take that to mean the lookup
>> implementing this fina feature should be a contextual lookup that
>> fires only when the و is following a left-joining character.
>>
>> As an alternative wording, could we consider something along the
>> lines
>> of:
>>
>> Example: In an Arabic script font, the application would apply the
>> fina feature to the letter و when it follows a left-joining
>> character, thereby replacing the current و glyph with its
>> right-joining final form.
>>
>> Similar wording could be created for the other features.
>
> I'll wait until I hear back from Vlad regarding whether the proposal will be considered for the current ballot. If so, I'll forward your mail as a comment. In not, I'll look at incorporating your suggestion in a revised submission. However, I note that the structure of OpenType Layout GSUB feature descriptions is such that the section in question generally doesn't imply anything about implementation, but only an example of the glyph substitution.
>
> JH
>
>
> --
>
> John Hudson
> Tiro Typeworks Ltd www.tiro.com
> Salish Sea, BC tiro at tiro.com
>
> Getting Spiekermann to not like Helvetica is like training a cat to
> stay out of water. But I'm impressed that people know who to ask when
> they want to ask someone to not like Helvetica. That's progress. --
> David Berlow
>
> _______________________________________________
> Opentype-layout mailing list
> Opentype-layout at unicode.org
> http://unicode.org/mailman/listinfo/opentype-layout
>
> _______________________________________________
> Opentype-layout mailing list
> Opentype-layout at unicode.org
> http://unicode.org/mailman/listinfo/opentype-layout
_______________________________________________
Opentype-layout mailing list
Opentype-layout at unicode.org
http://unicode.org/mailman/listinfo/opentype-layout
More information about the mpeg-otspec
mailing list