A Tale of Three (OpenType) Features

In an effort to make sure that the infrastructure to support UTR #50 (Unicode Vertical Text Layout) will be in place—sooner rather than later—I spent a significant part of last week working with key people within Adobe, and at Microsoft and W3C, to put together a proposal for a new OpenType feature, to be tagged ‘vrtr’, for supporting this soon-to-be published standard. Below is full description that we came up with, and which was submitted for inclusion in the OpenType Specification and in OFF (ISO/IEC 14496-22 or Open Font Format):

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.


We also used the opportunity to revise the description of the registered ‘vert‘ GSUB feature to better align it with both current practice and UTR #50 compliance:

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.

The third feature that is worth mentioning, and which is referenced in the two feature descriptions above, is ‘vrt2‘, but we decided to leave its description as-is, mainly because its use is out of the scope of UTR #50 compliance.

The next obvious steps are to bring key and relevant layout engines into UTR #50 compliance.

Comments are closed.