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

[Ken Lunde]

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://www.unicode.org/charts/PDF/U1100.pdf) and [Hangul Jamo Extended-B](https://www.unicode.org/charts/PDF/UD7B0.pdf) 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://www.w3.org/TR/jlreq/) 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://www.w3.org/TR/jlreq/) 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://blogs.adobe.com/CCJKType/2018/04/contextual-spacing.html

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
> 
>  
> 
>