Two proposals: 1) Register a new OpenType feature (vrtr) & 2) Update a registered OpenType feature description (vert)

[Ken Lunde]

All,

Two proposals are included below, one of which is to register a new OpenType feature in order to better support the approved-but-not-yet-published UTR #50, and the other is to modify the description of a register OpenType feature to comply with current practice, and to better support UTR #50. Here is the latest draft of UTR #50:

  http://www.unicode.org/reports/tr50/

The first proposal is to register a new OpenType feature to be tagged 'vrtr', and the full description is below (note that NCRs are used to represent non-ASCII characters in the "Example" section):

----------------
Tag: 'vrtr'

Friendly name: Vertical Alternates For Rotation

Registered by: Adobe/Microsoft/W3C

Function: Transforms default glyphs into glyphs that are appropriate for sideways presentation in vertical writing mode. While the glyphs for most characters in East Asian writing systems remain upright when set in vertical writing mode, glyphs for other characters -- such as those of other scripts or for particular Western-style punctuation -- are expected to be presented sideways in vertical writing.

Example: As a first example, the glyphs for FULLWIDTH LESS-THAN SIGN (U+FF1C; "＜") and FULLWIDTH GREATER-THAN SIGN (U+FF1E; "＞") in a font with a non-square em-box are transformed into glyphs whose aspect ratio differs from the default glyphs, which are properly sized for sideways presentation in vertical writing mode. As a second example, the glyph for LEFT SQUARE BRACKET (U+005B, "[") in a brush-script font that exhibits slightly rising horizontal strokes may use an obtuse angle for its upper-left corner when in horizontal writing mode, but an alternate glyph with an acute angle for that corner is supplied for vertical writing mode.

Recommended implementation: The font includes versions of the glyphs covered by this feature that, when rotated 90 degrees clockwise by the layout engine for sideways presentation in vertical writing, differ in some visual way from rotated versions of the default glyphs, such as by shifting or shape. The vrtr feature maps the default glyphs to the corresponding to-be-rotated glyphs (GSUB lookup type 1).

Application interface: For GIDs found in the vrtr coverage table, the layout engine passes GIDs to the feature, then gets back new GIDs.

UI suggestion: This feature should be active by default for sideways runs in vertical writing mode.

Script/language sensitivity: Applies to any script when set in vertical writing mode.

Feature interaction: The vrtr and vert features are intended to be used in conjunction: vrtr for glyphs intended to be presented sideways in vertical writing, and vert for glyphs to be presented upright. Since they must never be activated simultaneously for a given glyph, there should be no interaction between the two features. These features are intended for layout engines that graphically rotate glyphs for sideways runs in vertical writing mode, such as those conforming to UTR#50. (Layout engines that instead depend on the font to supply pre-rotated glyphs for all sideways glyphs should use the vrt2 feature in lieu of vrtr and vert.) Because vrt2 supplies pre-rotated glyphs, the vrtr feature should never be used with vrt2, but may be used in addition to any other feature.
----------------


The second proposal is to modify the description of a registered OpenType feature, specifically the one tagged 'vert'. Please compare the modified description with the current description:

  http://www.microsoft.com/typography/otspec/features_uz.htm#vert

Here is the modified description (note that NCRs are used to represent non-ASCII characters in the "Example" section):


----------------
Tag: 'vert'

Friendly name: Vertical Alternates

Registered by: Adobe/Microsoft

Function: Transforms default glyphs into glyphs that are appropriate for upright presentation 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 -- for upright presentation in vertical writing mode.

Example: As a first example, the glyph for HIRAGANA LETTER SMALL A (U+3041; "ぁ") is transformed into a glyph that is shifted up and to the right, which is properly positioned for upright presentation in vertical writing mode. As a second example, the glyph for SQUARE MAIKURO (U+3343; "㍃"), whose component katakana characters are ordered from left to right then top to bottom (like horizontal writing mode), is transformed into a glyph whose component katakana characters are ordered from top to bottom then right to left (like vertical writing mode).

Recommended implementation: 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. The vert feature maps the default glyphs to the corresponding vertical glyphs (GSUB lookup type 1).

Application interface: For GIDs found in the vert coverage table, the layout engine passes GIDs to the feature, then gets back new GIDs.

UI suggestion: This feature should be active by default in vertical writing mode.

Script/language sensitivity: Applies only to scripts with vertical writing capability.

Feature interaction: The vert and vrtr features are intended to be used in conjunction: vert for glyphs to be presented upright, and vrtr for glyphs intended to be presented sideways in vertical writing. Since they must never be activated simultaneously for a given glyph, there should be no interaction between the two features. These features are intended for layout engines that graphically rotate glyphs for sideways runs in vertical writing mode, such as those conforming to UTR#50. (Layout engines that instead depend on the font to supply pre-rotated glyphs for all sideways glyphs should use the vrt2 feature in lieu of vert and vrtr.) Because vrt2 supplies pre-rotated glyphs, the vert feature should never be used with vrt2, but may be used in addition to any other feature.
----------------

Regards...

-- Ken