[mpeg-OTspec] Draft amendment - any additional changes?

Rob McKaughan robmck at microsoft.com
Thu Mar 7 20:32:09 CET 2019 

The ballot comments indicates that only the Function and Example fields should be reverted to the existing: 'Remove modified descriptions of the “Function” and “Examples” fields of the ‘vert’ feature, to keep them as they are currently specified as part of the ISO/IEC 14496 22:2019 (4th edition).'

I believe it should also revert the Recommended Implementation and Application Interface sections of the 'vert' feature as well. Specifically, the following additions should be reverted:

Recommended Implementation: 'For glyphs that require repositioning for vertical writing mode, the font specifies alternate metrics (GPOS lookup type 1)'

Application Interface: 'the application passes GIDs to the lookup tables associated with the feature, ... (GSUB) or positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance)"

I'm fine keeping the Unicode references as Ken pointed out a few days ago.

Going forward, beyond this ballot, the next step is for us to document the existing implementation so that other implementors can understand it. Then we can agree on a common solution, which may be either to adopt the current implementation or come to consensus on a new proposal, which may end up being very like Ken's. We can't commit to a timeline for the document (just as neither Ken nor I can commit to an implementation schedule), but we recognize this is a very important issue. 

Thanks!
// Rob
	

-----Original Message-----
From: Ken Lunde <lunde at adobe.com> 
Sent: Thursday, March 7, 2019 5:53 AM
To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
Cc: mpeg-OTspec at yahoogroups.com; Ned Holbrook <ned at apple.com>; Behdad Esfahbod <behdad at behdad.org>; Rob McKaughan <robmck at microsoft.com>
Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes?

Vladimir,

I am okay with the content.

-- Ken

> On Mar 6, 2019, at 10:09 AM, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com> wrote:
> 
> Dear Ken, all,
> 
> Please see attached ballot comments document, which was prepared based on previously discussed comments. Your comments and suggested changes (if any) are much appreciated. We will need to finalize and submit this document by the end of day Friday, if I do not receive any comments or objections I will submit it as is.
> 
> Thank you,
> Vladimir
> 
> 
> -----Original Message-----
> From: Ken Lunde <lunde at adobe.com>
> Sent: Tuesday, March 5, 2019 3:49 PM
> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
> Cc: mpeg-OTspec at yahoogroups.com; Ned Holbrook <ned at apple.com>; Behdad 
> Esfahbod <behdad at behdad.org>; Rob McKaughan <robmck at microsoft.com>
> Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes?
> 
> Vladimir,
> 
> About the first point, I mainly wanted to make sure that things such as changing "Unicode Technical Report #50: Unicode vertical text Layout" to "Unicode Standard Annex #50: Unicode Vertical Text Layout [23]" in the "Feature interaction" section of the 'vert' feature was kept.
> 
> About the second point, retracting the changes to the 'vert' feature is not contingent on Microsoft taking an Action Item to provide the implementation details, but rather that other implementations, including fonts, will be in effective limbo until that happens. I mainly want to reserve the right to re-propose the changes to the 'vert' feature in the future if the implementation details are not supplied within a reasonable timeframe. I imagine that the developers of CoreText and HarfBuzz feel the same as me. We have real-world implementations that depend on this, and we'd like to be as cross-platform as possible.
> 
> Regards...
> 
> -- Ken
> 
>> On Mar 5, 2019, at 10:59 AM, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com> wrote:
>> 
>> Hi Ken,
>> 
>> Just to clarify and make sure we are all on the same page here - I realized there were other improvements to the description of the 'vert' feature, this is why I only suggested removing updates for "Function" and "Examples" fields, where you suggested changes essentially restore them to their original version anyway. The rest of the changes for 'vert' feature description stay in the amendment unchanged, I didn't suggest to completely remove the amended text.
>> 
>> Regarding MS folks (Rob?) being on the hook to provide detailed description of 'vert' feature implementation - are you suggesting that the changes you proposed should be contingent on adding additional details in the current amendment, or are you agreeing to make the change now even the additional details are not yet ready to be disclosed and added to the spec?
>> 
>> Thank you,
>> Vlad
>> 
>> -----Original Message-----
>> From: Ken Lunde <lunde at adobe.com>
>> Sent: Tuesday, March 5, 2019 1:32 PM
>> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
>> Cc: mpeg-OTspec at yahoogroups.com; Ned Holbrook <ned at apple.com>; Behdad 
>> Esfahbod <behdad at behdad.org>; Rob McKaughan <robmck at microsoft.com>
>> Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes?
>> Importance: High
>> 
>> Vladimir,
>> 
>> While I am okay with removing wording that allows GPOS implementations of the 'vert' feature, at least for now, Microsoft needs to on the hook to fully describe their implementation that is said to make GPOS implementations of the 'vert' feature unnecessary, which would include the following:
>> 
>> 1) Expected metrics of affected glyphs, such as position and advances
>> 2) Details of the transforms when in vertical writing mode
>> 3) A list of affected characters
>> 
>> Without such details, other implementations, in particular CoreText and HarfBuzz, need to guess, which can lead to different results. It'd be helpful if someone from Microsoft takes ownership of that, and treats it as an Action Item.
>> 
>> About restoring the text for 'vert' back to its original form, there were other improvements, which is why my adjustment instructions affected only the GPOS-related details.
>> 
>> Regards...
>> 
>> -- Ken
>> 
>>> On Mar 5, 2019, at 8:42 AM, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com> wrote:
>>> 
>>> Hi Ken, Rob, all,
>>> 
>>> We need to finalize our ballot comments by the end of this week. 
>>> (This is a short ballot period and the bureaucracy of the whole 
>>> process takes time to issue the ballot and collect comments - sorry 
>>> for a short notice.)
>>> 
>>> Looking at the comments that Ken offered below, it seems that:
>>> - With the suggested changes implemented to the description of "Function" field - the text is effectively restored back to its original form in the current ISO document. Therefore, it makes sense to simply submit a ballot comment asking to remove the proposed change.
>>> - The same seems to be the case for the text of "Examples" section - removing the last example restores that text  to its current form. Suitable ballot comment would be to remove the proposed changes of "Example" field.
>>> 
>>> Ken, Rob - Please confirm these suggestions, and also please confirm that there are no other changes we want to introduce in the description of the 'vert' feature. Also, if we do expect to provide more details about the existing logic and coverage for this feature, we need to do it by the end of this week at the latest - I do need to submit the finalized ballot comments document by end of day Friday in order to avoid missing the deadline.
>>> 
>>> Thank you,
>>> Vlad
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Ken Lunde <lunde at adobe.com>
>>> Sent: Sunday, February 10, 2019 10:27 AM
>>> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
>>> Cc: mpeg-OTspec at yahoogroups.com; Ned Holbrook <ned at apple.com>; 
>>> Behdad Esfahbod <behdad at behdad.org>; Rob McKaughan 
>>> <robmck at microsoft.com>
>>> Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes?
>>> 
>>> Vladimir and others,
>>> 
>>> I appreciate that Rob made the effort to look into this, and to report Microsoft's stance on my suggested changes to the 'vert' feature. This spans pp 18 and 19 in the draft amendment. It affects nothing else.
>>> 
>>> Given that this is a "division of labor" difference between major implementations, with Microsoft's implementations (DirectWrite and GDI) performing the positioning transforms to the glyphs of particular characters, and others (HarfBuzz and CoreText) expecting the fonts to specify the transforms in the 'vert' GPOS feature, I think it is fair to request that the stakeholders for the latter implementations -- Behdad for HarfBuzz and maybe Ned (Apple) for CoreText (CCed for good measure) -- chime in.
>>> 
>>> Also, I think it is fair to request more details from Microsoft about the logic (the default/expected glyph metrics and glyph position, along with the transform values) and coverage (code points) of their implementation. This is mainly for the benefit of other implementations, and should be detailed somewhere in the spec. I am aware of the following code points and code point ranges requiring this treatment, but there may be others:
>>> 
>>> U+20DD & U+20DE
>>> U+302A through U+302D
>>> U+3099 & U+309A
>>> U+1160 through U+11A7 & U+D7B0 through U+D7C6 (vowel jamo)
>>> U+11A8 through U+11FF & U+D7CB through U+D7FB (trailing jamo)
>>> 
>>> In our font implementations (Source Han and Noto CJK), the glyphs for the characters listed above are zero-width and are positioned to the left of the origin (coordinate 0,0).
>>> 
>>> Adobe's text layout implementations are actually at a crossroads, because we do neither at present, meaning that we would follow the consensus.
>>> 
>>> Anyway, if the GPOS aspect of 'vert' is to be removed, which is probably a good idea given that there is a controversy, the draft amendment should be adjusted as described below in the section about this feature:
>>> 
>>> 1) Remove the following two statements from the "Function" section:
>>> 
>>> or adjusts the position of glyphs so that they are positioned 
>>> correctly in vertical writing mode
>>> 
>>> or repositioned
>>> 
>>> 2) Remove the fourth example in the "Example" section:
>>> 
>>> In vertical writing mode, and for fonts that support combining jamo, the glyphs for vowel and trailing jamo in the HANGUL JAMO (U+1100; "ᄀ") and HANGUL JAMO EXTENDED-B (U+D7B0; "ힰ") blocks are repositioned along both axes such that they combine correctly, which involves adjustments to the XPlacement, YPlacement, and YAdvance value records.
>>> 
>>> 3) Remove the last sentence from the "Recommended implementation" section:
>>> 
>>> For glyphs that require repositioning for vertical writing mode, the font specifies alternate metrics (GPOS lookup type 1).
>>> 
>>> 4) Remove the following statement from the "Application interface" section:
>>> 
>>> or positional adjustments (XPlacement, XAdvance, YPlacement and
>>> YAdvance)
>>> 
>>> Regards...
>>> 
>>> -- Ken
>>> 
>>>> On Feb 8, 2019, at 7:35 AM, Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com> wrote:
>>>> 
>>>> Thank you Rob and Ken for reviewing the proposed changes again, and for providing your input.
>>>> 
>>>> Do you plan to (either jointly or as individual contributions) provide an update to what is currently included in the draft amendment? It sounds like certain parts of the suggested changes are expected to be modified, and the current text of the standard needs to be updated to clarify the existing solution for vertical typesetting. Both changes can be introduced via ballot comments, but we do need to discuss and submit the proposed comments for ISO consideration.
>>>> 
>>>> Thank you,
>>>> Vladimir
>>>> 
>>>> 
>>>> From: Rob McKaughan <robmck at microsoft.com>
>>>> Sent: Thursday, February 7, 2019 6:03 PM
>>>> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>; Ken 
>>>> Lunde <lunde at adobe.com>
>>>> Cc: mpeg-OTspec at yahoogroups.com
>>>> Subject: RE: [mpeg-OTspec] Draft amendment - any additional changes?
>>>> 
>>>> Apologies for taking a long time to respond to Ken Lunde’s proposal on the ‘vert’ feature.
>>>> 
>>>> After talking with people in the GDI and DirectWrite teams, we are recommending against this proposal. There is an existing solution for vertical typesetting that has been implemented in OpenType and Microsoft products for over 25 years, with good customer feedback and a plethora of fonts developed for it. It also supports components like Jamo so that space-efficient East Asian fonts can be created. Finally, though poorly documented, it has a quarter century of momentum behind it. 
>>>> 
>>>> To its credit, Ken’s proposal does provide greater flexibility for font makers, and enables Harfbuzz and CoreText platforms to support vertical typesetting with no code changes; however, it does not address the existing solution or the impact of the proposal on it. I.e. fonts designed per the new proposal will not work on platforms that implement the existing solution. Even if the proposal went forward as-is, it would create a problem for font makers because they would not have a way to build a single font on all the platforms. This problem is only made worse by the fact that, neither of the two platform makers that do require code changes to support the proposal (i.e. Adobe and Microsoft) can commit to the change. 
>>>> 
>>>> For our part, we will look into better documenting the current solution for platform makers so that it is easier and clearer to implement.
>>>> 
>>>> // Rob
>>>> 
>>>> 
>>>> From: mpeg-OTspec at yahoogroups.com <mpeg-OTspec at yahoogroups.com> On 
>>>> Behalf Of Rob McKaughan robmck at microsoft.com [mpeg-OTspec]
>>>> Sent: Tuesday, January 8, 2019 9:36 AM
>>>> To: Levantovsky, Vladimir <vladimir.levantovsky at monotype.com>; Ken 
>>>> Lunde <lunde at adobe.com>
>>>> Cc: mpeg-OTspec at yahoogroups.com
>>>> Subject: RE: [mpeg-OTspec] Draft amendment - any additional changes?
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> First off, I apologize for being late to this discussion. I appreciate that Ken made his proposal some time ago.
>>>> 
>>>> Previously, the specification proposed that the vert feature be implemented with GSUB single substitutions. This proposal also allows vert to appear in GPOS (specifically, type 1 lookups, it appears). There is a concern that our text stacks assume only GSUB single substitutions. We need some time to look into this – e.g. is there no problem? Is there something that architecturally or logically prevents this from being implemented? I am following up with various teams at MS on this.
>>>> 
>>>> Meanwhile, I wonder: do Apple and Google text stacks have any similar assumptions? Again, apologies for being new to the discussion.
>>>> 
>>>> I’m not sure procedurally what needs to happen, but I’m sure that we can’t get this resolved today. I will, however, move as fast as I can on it.
>>>> 
>>>> Thanks,
>>>> // Rob
>>>> 
>>>> 
>>>> 
>>>> From: mpeg-OTspec at yahoogroups.com <mpeg-OTspec at yahoogroups.com> On 
>>>> Behalf Of 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com 
>>>> [mpeg-OTspec]
>>>> Sent: Friday, January 4, 2019 11:27 AM
>>>> To: Ken Lunde <lunde at adobe.com>
>>>> Cc: mpeg-OTspec at yahoogroups.com
>>>> Subject: RE: [mpeg-OTspec] Draft amendment - any additional changes?
>>>> 
>>>> 
>>>> + mpeg-OTspec list
>>>> 
>>>> Hi Ken, all,
>>>> 
>>>> Like Ken mentioned in his email, it appears that something is broken on Yahoo Groups server that prevents attachments from being downloaded from the email link - there are two links embedded in my original email (one in the beginning and another one in the very end) - none of them work. 
>>>> 
>>>> However, there is also "View attachments on the web" link, which brings you to their web interface - you need to be logged in using the same Yahoo profile you used to sign up to this group email list, but once logged in - you can see and download the attachment from the web archive. 
>>>> 
>>>> It is unfortunate that their email attachments do not work (hopefully something Yahoo will fix soon) but, at least, there is a way to get a document downloaded for review. If you are not able to do it for whatever reason, please contact me directly and I will email you a standalone copy. 
>>>> 
>>>> Thank you,
>>>> Vlad
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Ken Lunde <lunde at adobe.com>
>>>> Sent: Friday, January 4, 2019 1:16 PM
>>>> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
>>>> Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes? 
>>>> [1 Attachment]
>>>> 
>>>> Vladimir,
>>>> 
>>>> Just FYI, the link to the document appears to be broken or malformed. I tried two different email clients. 
>>>> 
>>>> -- Ken
>>>> 
>>>>> On Jan 4, 2019, at 10:07 AM, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote: 
>>>>> 
>>>>> [Attachment(s) from Levantovsky, Vladimir included below] Ken, 
>>>>> all,
>>>>> 
>>>>> Please see attached the draft input contribution for WG11 meeting 
>>>>> summarizing the proposed changes and additional amendments to the 
>>>>> ISO/IEC 14496-22 "OFF". (Changes to existing text are 
>>>>> highlighted.)
>>>>> 
>>>>> Notably, this draft text deviates in small parts from what Ken originally proposed by adopting the change to the 'ZHTM' language tag proposed by Peter Constable, also including editorial modifications to follow the established conventions for glyph references in feature tag descriptions and replacing some inline links with bibliographic references. 
>>>>> 
>>>>> Your comments and additional suggested changes (if any) are very much appreciated and should be submitted no later than end of day Monday, Jan. 7, 2019. As usual, silence is approval - if I don’t hear from you by end of day Monday I will submit the current draft as a finalized AHG input contribution. 
>>>>> 
>>>>> Thank you,
>>>>> Vladimir
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Levantovsky, Vladimir
>>>>> Sent: Wednesday, January 2, 2019 3:19 PM
>>>>> To: 'Ken Lunde' <lunde at adobe.com>
>>>>> Cc: mpeg-OTspec at yahoogroups.com; Rob McKaughan 
>>>>> <robmck at microsoft.com>; Harneet Sidhana <harneets at microsoft.com>; 
>>>>> Koji Ishii <kojiishi at gmail.com>
>>>>> Subject: RE: [mpeg-OTspec] Draft amendment - any additional changes? 
>>>>> [1 Attachment]
>>>>> Importance: High
>>>>> 
>>>>> Dear all,
>>>>> 
>>>>> Happy New Year, and best wishes for 2019! 
>>>>> 
>>>>> I am following up on Ken Lunde's proposal (see below) to solicit your comments - both on the proposed language updates for the existing feature descriptions 'vert' and 'vrtr', and new proposed feature tags 'chws' and 'vchw'. We already have an agreement to use 'ZHTM' for new "Chinese, Macao SAR" language tag registration, the feature tags are the only remaining items that have not been discussed yet. 
>>>>> 
>>>>> We need to finalize this and prepare an input contribution for the upcoming WG11 meeting (coming up on January 14-18, 2019); the submission deadline for input contribution is end of day Jan. 7, 2019 (Monday next week). If any of you have an objection to the proposed changes, or if you would like to suggest any additional changes - please respond on this email list no later than end of day Friday, January 4th. 
>>>>> As usual, silence is treated as approval so please speak up! 
>>>>> 
>>>>> Thank you,
>>>>> Vladimir
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Ken Lunde <lunde at adobe.com>
>>>>> Sent: Saturday, December 8, 2018 12:01 PM
>>>>> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com>
>>>>> Cc: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk; Rob 
>>>>> McKaughan <robmck at microsoft.com>; Harneet Sidhana 
>>>>> <harneets at microsoft.com>; Koji Ishii <kojiishi at gmail.com>
>>>>> Subject: Re: [mpeg-OTspec] Draft amendment - any additional changes? 
>>>>> [1 Attachment]
>>>>> 
>>>>> Vladimir,
>>>>> 
>>>>> The following are additional changes that I propose for the amendment, listed in four numbered sections: 
>>>>> 
>>>>> 1) Modify the description of the 'vert' feature to explicitly allow GPOS implementations that already exist, in terms of fonts and layout engines. 
>>>>> 
>>>>> Below is a modified version of the "Function" section: 
>>>>> 
>>>>> Transforms default glyphs into glyphs that are appropriate for upright presentation in vertical writing mode, or adjusts the position of glyphs so that they are positioned correctly in vertical writing mode. While the glyphs for most characters in East Asian writing systems remain upright when set in vertical writing mode, some must be transformed — usually by rotation, shifting, or different component ordering — or repositioned for vertical writing mode. 
>>>>> 
>>>>> Below is an additional paragraph for the "Example" section (I used markdown syntax to specify text that should be links): 
>>>>> 
>>>>> In vertical writing mode, and for fonts that support combining jamo, the glyphs for vowel and trailing jamo in the [Hangul Jamo](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.unicode.org-5Fcharts-5FPDF-5FU1100.pdf-2526d-253DDwIGaQ-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253Djb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5-2526m-253D8zsAQ-5F0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY-2526s-253Dyw-2DeW8uaiVKwMStrZDetxIx4-5FK6aB-2DSJNLJKBvb-5FNWA-2526e-26amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C1b1fb6c2c88d4936a42f08d6a1899d61-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636874009770396725-26amp-3Bsdata-3D-252BF9J-252FZ1oTySI7z-252FJSm2uQza-252FU0jhaF82Bptgxbn4OzY-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DSc-ry7Q3xvBnomEBkMoE2_ivmrUn9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ%26m%3DJkNBbTxzJrU5F7d461RYvfnAKfpzcO8SiQ7C2_F_UtE%26s%3Dmr1QeaQPt-iN5qqwIlSo8nLTsE0smAKQQvJQcijdcV8%26e&data=02%7C01%7Crobmck%40microsoft.com%7C2393310966684077cf8808d6a30429a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875635617582473&sdata=x50PbmOt77ByzDJc2HkzQYsGvKJNH1LJ55h1UQc2uNU%3D&reserved=0=) and [Hangul Jamo Extended-B](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.unicode.org-5Fcharts-5FPDF-5FUD7B0.pdf-2526d-253DDwIGaQ-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253Djb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5-2526m-253D8zsAQ-5F0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY-2526s-253DIUeGQF3WWMZYRXPkojCtqirfMrISTOrqjqYSgODWGhY-2526e-26amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C1b1fb6c2c88d4936a42f08d6a1899d61-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636874009770406733-26amp-3Bsdata-3Dlnv-252FPKja3NMkSf44QtRfTleuIdnfqqLwb-252FBHM0Qz210-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DSc-ry7Q3xvBnomEBkMoE2_ivmrUn9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ%26m%3DJkNBbTxzJrU5F7d461RYvfnAKfpzcO8SiQ7C2_F_UtE%26s%3Dk6pf6cdRm6dhWHm2ddZhPuKLYOwMAyuQBQPCNM7gnak%26e&data=02%7C01%7Crobmck%40microsoft.com%7C2393310966684077cf8808d6a30429a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875635617592481&sdata=3qcsTwMsUjbMvgNZSWWRH4YXlhCGnPJj5RVzbvB0NDE%3D&reserved=0=) blocks are repositioned along both axes such that they combine correctly, which involves adjustments to the XPlacement, YPlacement, and YAdvance value records. 
>>>>> 
>>>>> Below is a modified version of the "Recommended implementation" section: 
>>>>> 
>>>>> The font includes versions of the glyphs covered by this feature that differ in some visual way from the default glyphs, such as by rotation, shifting, or different component ordering. For such glyphs, the 'vert' feature maps the default glyphs to the corresponding, alternate glyphs for vertical writing mode using a type 1 (single substitution) GSUB lookup. For glyphs that require repositioning for vertical writing mode, the font specifies alternate metrics (GPOS lookup type 1). 
>>>>> 
>>>>> Below is a modified version of the "Application interface" section: 
>>>>> 
>>>>> For GIDs found in the 'vert' coverage table, the application passes GIDs to the lookup tables associated with the feature, then gets back new GIDs (GSUB) or positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance). 
>>>>> 
>>>>> Lastly, change "Unicode Technical Report" to "Unicode Standard Annex" in the first paragraph of the "Feature interaction" section. 
>>>>> 
>>>>> 
>>>>> 2) In the description of the 'vrtr' feature, change "Unicode Technical Report" to "Unicode Standard Annex" in the first paragraph of the "Feature interaction" section. 
>>>>> 
>>>>> 
>>>>> 3) Per recent discussions on the mailing list, register the following new language tag for the Layout Tag Registry: 
>>>>> 
>>>>> ZHM Chinese, Macao SAR (ISO 639 ID is zho)
>>>>> 
>>>>> Background: Traditional Chinese is used in three main regions: Taiwan (aka ROC), Hong Kong SAR, and Macao SAR. Language tags for the first two have already been registered: ZHT and ZHH. Their conventions, in terms of the shapes of their components, are sufficiently different that Pan-CJK implementations which support the 'locl' GSUB feature require separate language tags so that the appropriate region-specific glyphs can be displayed.. The conventions for Hong Kong SAR are best described as a hybrid of those of China (PRC) and Taiwan (ROC), along with components whose forms are unique to Hong Kong SAR. Likewise, the conventions for Macao SAR can be described as a hybrid of those of Taiwan (ROC) and Hong Kong SAR, and by extension, those of China (PRC). 
>>>>> 
>>>>> 
>>>>> 4) Register two new features for the Layout Tag Registry whose complete descriptions are below: 
>>>>> 
>>>>> Tag: 'chws' 
>>>>> 
>>>>> Friendly name: Contextual Half-width Spacing
>>>>> 
>>>>> Registered by: Adobe/W3C
>>>>> 
>>>>> Function: Contextually respaces glyphs designed to be set on full-em widths, fitting them onto individual half-width horizontal widths, to approximate more sophsticated text layout, such as what is described in [Requirements for Japanese Text Layout (JLREQ)](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.w3.org-5FTR-5Fjlreq-5F-2526d-253DDwIGaQ-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253Djb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5-2526m-253D8zsAQ-5F0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY-2526s-253Du6erLE0xe7mZxhDdpjikFHdjAJxC-2D7InNYjPFDultCk-2526e-26amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C1b1fb6c2c88d4936a42f08d6a1899d61-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636874009770406733-26amp-3Bsdata-3DqxL-252BV0YURtOU4sihAb6v-252BSWgQE9TR-252FMUODIyeOal-252BT4-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DSc-ry7Q3xvBnomEBkMoE2_ivmrUn9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ%26m%3DJkNBbTxzJrU5F7d461RYvfnAKfpzcO8SiQ7C2_F_UtE%26s%3DXHO45ORJ3qpTuc6udXo4kXhf3BxMq5fm0enCyGkr-YY%26e&data=02%7C01%7Crobmck%40microsoft.com%7C2393310966684077cf8808d6a30429a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875635617592481&sdata=mrWl4pFWGfn6vhAVy8f6SnspLI0sPyOJ2%2FB2TZerS4g%3D&reserved=0=) or similar CJK text-layout specifications that expect half-width forms of characters whose default glyphs are full-width. This differs from 'halt' in that the respacing is contextual. This feature may be invoked to get better fit for punctuation or symbol glyphs without disrupting the monospaced alignment, such as for UIs or terminal apps. 
>>>>> 
>>>>> Example: When U+FF09 ） FULLWIDTH RIGHT PARENTHESIS is followed by U+3001 、 IDEOGRAPHIC COMMA, the latter is respaced to remove half-em of width between them. 
>>>>> 
>>>>> Recommended implementation: The font stores a set of adjustments for pairs of glyphs (GPOS lookup type 2 or 8). These may be stored as one or more tables matching left and right classes, &/or as individual pairs. Additional adjustments may be provided for larger sets of glyphs (e.g. triplets, quadruplets, etc.) to overwrite the results of pair kerns in particular combinations. 
>>>>> 
>>>>> Application interface: The application passes a sequence of GIDs to the 'chws' table, and gets back adjusted positions (XPlacement, XAdvance, YPlacement, and YAdvance) for those GIDs. When using the type 2 lookup on a run of glyphs, it’s critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior). 
>>>>> 
>>>>> UI suggestion: This feature would be off by default. 
>>>>> 
>>>>> Script/language sensitivity: Used mostly in CJKV fonts. 
>>>>> 
>>>>> Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g., 'fwid', 'halt', 'hwid', 'palt', 'pwid', 'qwid', 'twid'), which should be turned off when this feature is applied. It deactivates the 'kern' feature. See also 'vchw'. 
>>>>> 
>>>>> 
>>>>> Tag: 'vchw' 
>>>>> Friendly name: Vertical Contextual Half-width Spacing
>>>>> 
>>>>> Registered by: Adobe/W3C
>>>>> 
>>>>> Function: Contextually respaces glyphs designed to be set on full-em heights, fitting them onto individual half-width vertical heights, to approximate more sophsticated text layout, such as what is described in [Requirements for Japanese Text Layout (JLREQ)](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fwww.w3.org-5FTR-5Fjlreq-5F-2526d-253DDwIGaQ-2526c-253DeuGZstcaTDllvimEN8b7jXrwqOf-2Dv5A-5FCdpgnVfiiMM-2526r-253Djb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5-2526m-253D8zsAQ-5F0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY-2526s-253Du6erLE0xe7mZxhDdpjikFHdjAJxC-2D7InNYjPFDultCk-2526e-26amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C1b1fb6c2c88d4936a42f08d6a1899d61-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636874009770406733-26amp-3Bsdata-3DqxL-252BV0YURtOU4sihAb6v-252BSWgQE9TR-252FMUODIyeOal-252BT4-253D-26amp-3Breserved-3D0-3D%26d%3DDwIGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DSc-ry7Q3xvBnomEBkMoE2_ivmrUn9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ%26m%3DJkNBbTxzJrU5F7d461RYvfnAKfpzcO8SiQ7C2_F_UtE%26s%3DXHO45ORJ3qpTuc6udXo4kXhf3BxMq5fm0enCyGkr-YY%26e&data=02%7C01%7Crobmck%40microsoft.com%7C2393310966684077cf8808d6a30429a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875635617592481&sdata=mrWl4pFWGfn6vhAVy8f6SnspLI0sPyOJ2%2FB2TZerS4g%3D&reserved=0=) or similar CJK text-layout specifications that expect half-width forms of characters whose default glyphs are full-width. This differs from 'vhal' in that the respacing is contextual. This feature may be invoked to get better fit for punctuation or symbol glyphs without disrupting the monospaced alignment. 
>>>>> 
>>>>> Example: When U+FE36 ︶ PRESENTATION FORM FOR VERTICAL RIGHT PARENTHESIS (vertical form of U+FF09 ）FULLWIDTH RIGHT PARENTHESIS) is followed by U+FE11 ︑ PRESENTATION FORM FOR VERTICAL IDEOGRAPHIC COMMA (vertical form of U+3001 、 IDEOGRAPHIC COMMA), the latter is respaced to remove half-em of height between them. 
>>>>> 
>>>>> Recommended implementation: The font stores a set of adjustments for pairs of glyphs (GPOS lookup type 2 or 8). These may be stored as one or more tables matching left and right classes, &/or as individual pairs. Additional adjustments may be provided for larger sets of glyphs (e.g. triplets, quadruplets, etc.) to overwrite the results of pair kerns in particular combinations. 
>>>>> 
>>>>> Application interface: The application passes a sequence of GIDs to the 'vchw' table, and gets back adjusted positions (XPlacement, XAdvance, YPlacement, and YAdvance) for those GIDs. When using the type 2 lookup on a run of glyphs, it’s critical to remember to not consume the last glyph, but to keep it available as the first glyph in a subsequent run (this is a departure from normal lookup behavior). 
>>>>> 
>>>>> UI suggestion: This feature would be off by default. 
>>>>> 
>>>>> Script/language sensitivity: Used mostly in CJKV fonts. 
>>>>> 
>>>>> Feature interaction: This feature is mutually exclusive with all other glyph-height features (e.g., 'valt', 'vhal', 'vpal'), which should be turned off when this feature is applied. It deactivates the 'vkrn' feature. See also 'chws'. 
>>>>> 
>>>>> 
>>>>> For those who are interested in the background for these two new features, please read the following CJK Type Blog article from earlier this year: 
>>>>> 
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fna01.safelinks-26amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C939c9bd86ae4497362cd08d6a19cc828-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636874092118176631-26amp-3Bsdata-3D-252BwyPLPXQcKhhVl5z-252FIHGBx3hPs9a8nfEugLaEur-252FZiQ-253D-26amp-3Breserved-3D0%26d%3DDwIGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3DSc-ry7Q3xvBnomEBkMoE2_ivmrUn9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ%26m%3D7Jvr2ju2X9Ls_mBOGnznFz1RQDbIiFwPYQxnu2aOeGQ%26s%3DcpL1nnKN9F3Uv2gm35THBkpRhmIr4_DUMlY44glB4Uk%26e&data=02%7C01%7Crobmck%40microsoft.com%7C2393310966684077cf8808d6a30429a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636875635617592481&sdata=nkOTCmnr5M0Knen4nXQr85XMOD7%2BkMNQRo%2BE97oYQYs%3D&reserved=0=.
>>>>> protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.pro
>>>>> o
>>>>> f
>>>>> point.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fblogs.adobe.com
>>>>> -
>>>>> 2
>>>>> 6amp-3Bdata-3D02-257C01-257Clunde-2540adobe.com-257C1b1fb6c2c88d49
>>>>> 3
>>>>> 6
>>>>> a42f08d6a1899d61-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-
>>>>> 2
>>>>> 5
>>>>> 7C636874009770406733-26amp-3Bsdata-3DCe6n-252BwBWd6o7-252FSiuV-252
>>>>> B
>>>>> s
>>>>> TkItt8EI8FUutENBTn2Vljcs-253D-26amp-3Breserved-3D0&d=DwIGaQ&c=euGZ
>>>>> s
>>>>> t
>>>>> caTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=Sc-ry7Q3xvBnomEBkMoE2_ivmr
>>>>> U
>>>>> n
>>>>> 9t3iPURPqMYwR3mRAaAfoxAAQdIUO6oCmSDQ&m=JkNBbTxzJrU5F7d461RYvfnAKfp
>>>>> z c 
>>>>> O8SiQ7C2_F_UtE&s=HQEhBDOeJTdoIQkdeMhV1lTQcjHNqSHo7tlWceKX5wM&e=
>>>>> _C
>>>>> CJKType_2018_04_contextual-2Dspacing.html&d=DwIGaQ&c=euGZstcaTDllv
>>>>> i
>>>>> m
>>>>> EN
>>>>> 8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs
>>>>> 4
>>>>> 6
>>>>> vO
>>>>> K4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3
>>>>> I Y Y& s=DvWu31U4NBEJOIbuuqU7nbnEd2QuEj1rqP6sn8l1w4Y&e=
>>>>> 
>>>>> The feature tags in the article differ from what is proposed above, and were the result of discussions on these mailing lists. 
>>>>> 
>>>>> Regards... 
>>>>> 
>>>>> -- Ken
>>>>> 
>>>>>> On Dec 7, 2018, at 8:39 AM, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com> wrote: 
>>>>>> 
>>>>>> [Attachment(s) from Levantovsky, Vladimir included below]
>>>>>> 
>>>>>> Dear all,
>>>>>> 
>>>>>> 
>>>>>> Based on our prior discussions and the proposal made earlier this year, we started a new draft OFF amendment at the last MPEG meeting in October (see attached for your reference). The main subject of the amendment were changes to SVG glyph descriptions, but we are not limited to this and can use this opportunity to make any additional changes. The amendment is expected to be finalized at the next meeting on January 14-18, 2019, so any additional changes would have to be discussed and agreed on no later than January 8, 2019. 
>>>>>> 
>>>>>> 
>>>>>> Please submit your proposed changes to this list. 
>>>>>> 
>>>>>> 
>>>>>> Thank you,
>>>>>> 
>>>>>> Vladimir
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> This email has been scanned for spam and viruses. Click here to report this email as spam.
>>>> 
>>> 
>> 
> 
> <l3.1-2019-00009-BallotComments-14496-22-PDAM1.doc>

More information about the mpeg-otspec mailing list