Feature description correct/change proposal

[Ken Lunde]

All,

I would like to propose a correction to the "Function" section of the 'vhal' GPOS feature, and a change to the "UI suggestion" section of the 'halt' and 'vhal' GPOS features.

Below are the current feature records (taken from Microsoft's website) for everyone's convenience:

Tag: 'halt'

Friendly name: Alternate Half Widths
Registered by: Adobe
Function: Respaces glyphs designed to be set on full-em widths, fitting them onto half-em widths. This differs from hwid in that it does not substitute new glyphs.
Example: The user may invoke this feature in a CJKV font to get better fit for punctuation or symbol glyphs without disrupting the monospaced alignment.
Recommended implementation: The font specifies alternate metrics for the full-width glyphs (GPOS lookup type 1).
Application interface: For GIDs found in the halt coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).
UI suggestion: This feature would be off by default.
Script/language sensitivity: Used only in CJKV fonts.
Feature interaction: This feature is mutually exclusive with all other glyph-width features (e.g. tnum, fwid, hwid, palt, twid), which should be turned off when it's applied. It deactivates the kern feature. See also vhal.

Tag: 'vhal'

Friendly name: Alternate Vertical Half Metrics
Registered by: Adobe
Function: Respaces glyphs designed to be set on full-em heights, fitting them onto half-em heights. This differs from valt in that it does not substitute new glyphs.
Example: The user may invoke this feature in a CJKV font to get better fit for punctuation or symbol glyphs without disrupting the monospaced alignment.
Recommended implementation: The font specifies alternate metrics for the full-height glyphs (GPOS lookup type 1).
Application interface: For GIDs found in the vhal coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance).
UI suggestion: This feature would be off by default.
Script/language sensitivity: Used only in CJKV fonts.
Feature interaction: This feature is mutually exclusive with all other glyph-height features (e.g. valt and vpal), which should be turned off when it's applied. It deactivates the kern feature. See also halt.


About the correction, the "This differs from valt in that it does not substitute new glyphs" sentence in the "Function" section of the 'vhal' GPOS feature is incorrect in that the 'valt' GPOS feature also does not substitute new glyphs (it was also effectively deprecated very early in the life of OpenType in favor of 'vmtx' table overrides that have an advantage in that they represent default behavior, and doesn't need to be manually enabled by the user or application). I suggest that this sentence simply be removed.


About the changes, I suggest that the "UI suggestion" for both features be changed to the following:

UI suggestion: This feature would be off by default, but CJK-aware text engines or applications that require half-width forms of glyphs that are full-width by default may selectively apply this feature to particular code points that correspond to characters that are important for CJK line-layout purposes, such as punctuation and brackets.


The background is that existing CJK-aware text engines and applications need to work with half-width versions of punctuation and brackets in order to apply line-layout rules that affect inter-character spacing, and almost all fonts provide these glyphs in full-width form. Such text engines and applications must mechanically remove half of the white space, such as on the left for opening brackets, on the right for most punctuation and closing brackets, and 25% on the left and right for centered punctuation. This mechanical trimming of the white space is prone to error, especially when different languages or regions place the glyph in a different portion of the em-box. U+3001 and U+3002 are excellent examples: in China and Japan they are left-justified in horizontal and upper-justified in vertical, but in Taiwan both are centered within the em-box. Applying these GPOS feature is much less prone to error, because the exact portion of white space that should be trimmed is clearly specified at the glyph level.

Below is a more complete list of characters whose glyph positions within the em-box can vary by language or region, and for which applying these GPOS features give correct results:

  U+3001 (left- or top-justified [depending on writing direction] for JP/CN; centered for TW/HK)
  U+3002 (left- or top-justified [depending on writing direction] for JP/CN; centered for TW/HK)
  U+FF01 (left- or top-justified [depending on writing direction] for CN; centered for JP/TW/HK)
  U+FF0C (left- or top-justified [depending on writing direction] for JP/CN; centered for TW/HK)
  U+FF0E (left- or top-justified [depending on writing direction] for JP/CN; centered for TW/HK)
  U+FF1A (left- or top-justified [depending on writing direction] for CN; centered/rotated for JP; centered for TW/HK)
  U+FF1B (left- or top-justified [depending on writing direction] for CN; centered for JP/TW/HK)
  U+FF1F (left- or top-justified [depending on writing direction] for CN; centered for JP/TW/HK)

While this doesn't need to be included in the GPOS feature descriptions, the following code points represent the punctuation and brackets form which half-width versions are useful for CJK line-layout purposes.

And yes, these GPOS features are already included in many CJK fonts. Adobe has been including them in our CJK fonts for about 15 years.

Regards...

-- Ken