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

Tue Jan 8 18:36:08 CET 2019

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<mailto:lunde at adobe.com>>
Sent: Friday, January 4, 2019 1:16 PM
To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com<mailto: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<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com<mailto: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<mailto:lunde at adobe.com>>
> Cc: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; Rob McKaughan <robmck at microsoft.com<mailto:robmck at microsoft.com>>;
> Harneet Sidhana <harneets at microsoft.com<mailto:harneets at microsoft.com>>; Koji Ishii
> <kojiishi at gmail.com<mailto: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<mailto:lunde at adobe.com>>
> Sent: Saturday, December 8, 2018 12:01 PM
> To: Levantovsky, Vladimir <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>
> Cc: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>; Rob
> McKaughan <robmck at microsoft.com<mailto:robmck at microsoft.com>>; Harneet Sidhana
> <harneets at microsoft.com<mailto:harneets at microsoft.com>>; Koji Ishii <kojiishi at gmail.com<mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_charts_PDF_U1100.pdf&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY&s=yw-eW8uaiVKwMStrZDetxIx4_K6aB-SJNLJKBvb_NWA&e=) and [Hangul Jamo Extended-B](https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_charts_PDF_UD7B0.pdf&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY&s=IUeGQF3WWMZYRXPkojCtqirfMrISTOrqjqYSgODWGhY&e=) 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_jlreq_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY&s=u6erLE0xe7mZxhDdpjikFHdjAJxC-7InNYjPFDultCk&e=) 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_jlreq_&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vOK4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY&s=u6erLE0xe7mZxhDdpjikFHdjAJxC-7InNYjPFDultCk&e=) 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://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.adobe.com_C
> CJKType_2018_04_contextual-2Dspacing.html&d=DwIGaQ&c=euGZstcaTDllvimEN
> 8b7jXrwqOf-v5A_CdpgnVfiiMM&r=jb2T9D8Np5j0t1X2JtGDVMxJyD5fvLoEPxzRs46vO
> K4UfGfOrlVsyuleed6YRZk5&m=8zsAQ_0stQBKP3Aik46G1aowA6dIIGdedvW78fu3IYY&
> 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<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com<mailto: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
> >
> >
> >
> >
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20190108/2086275f/attachment.html>