'vpal' vs. 'valt' feature description

[twardoch]

This is confusing: the valt description recommends GPOS, but the vpal description suggests that valt uses GSUB.

--

Tag: 'valt' Friendly name: Alternate Vertical Metrics

Registered by: Adobe (Modified by Adobe, this is the newer description)

Function: Repositions glyphs to visually center them within full-height metrics, for use in vertical setting. Typically applies to full-width Latin glyphs, which are aligned on a common horizontal baseline and not rotated when set vertically in CJKV fonts.

Example: Applying this feature would shift a Roman h down, or y up, from their default full-width positions.

Recommended implementation: The font specifies alternate metrics for the original glyphs (GPOS lookup type 1).

--

Tag: 'vpal' Friendly name: Proportional Alternate Vertical Metrics

Registered by: Adobe

Function: Respaces glyphs designed to be set on full-em heights, fitting them onto individual (more or less proportional) vertical heights. This differs from 'valt' in that it does not substitute new glyphs (GPOS, not GSUB feature). The user may prefer the monospaced form, or may simply want to ensure that the glyph is well-fit.

--

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: dd547c7a-0679-c1f5-9bd8-6e0249218aca
• Version Independent ID: 38e91354-2503-9b0c-c0da-a0cd808e1e35
• Content: Registered features, u-z - Typography
• Content Source: typographydocs/opentype/spec/features_uz.md
• Product: typography
• GitHub Login: @PeterCon
• Microsoft Alias: PeterCon

[kenlunde]

Yes, the second sentence in the Function description is incorrect. For 'vpal', it should be changed to the following:

This differs from 'valt' in that a different vertical advance is returned, one that is proportional.

The sentence that follows should be removed:

The user may prefer the monospaced form, or may simply want to ensure that the glyph is well-fit.

The same sentence in the Function description of the 'vhal' feature needs similar treatment:

This differs from 'valt' in that a different vertical advance is returned, one that is half-width.

[kenlunde]

In addition, please add the following statement to the 'valt' feature's "Recommended implementation" section:

The same functionality can be accomplished through the use of 'vmtx' table overrides by adjusting the vertical origin. This method is preferred, as it represents default behavior in vertical layout.

[PeterCon]

@kenlunde Two issues I'd like to see fixed:

1)

Typically applies to full-width Latin glyphs, which are aligned on a common horizontal baseline and not rotated when set vertically in CJKV fonts.

A problem when mentioning "rotation" (or "not rotated") is that there is ambiguity, since in vertical layout the baseline of entire lines are rotated. So, the wording should make clear the intent: "not rotated relative to the page" or "not rotated relative to the baseline.

2)

The same functionality can be accomplished through the use of 'vmtx' table overrides by adjusting the vertical origin.

The meaning of "'vmtx' overrides" is unclear. Is the intended meaning "through use of top side bearing values provided in the 'vmtx' table"? Use (for CFF) of VORG?

Could you suggest proposed changes to current feature descriptions that takes these add'l issues into consideration?

[kenlunde]

For 1, I suggest the following rewrite:

Applies to full-width Latin, Greek, or Cyrillic glyphs, which are typically included in East Asian fonts, and whose glyphs are aligned on a common horizontal baseline and not rotated relative to the page or text frame.

For 2, I suggest the following rewrite:

The same functionality can be accomplished by adjusting glyph vertical origins through the use of appropriate topSideBearing values in the 'vmtx' table, and corresponding vertOriginY values in the 'VORG' table (CFF only).

[PeterCon]

Please clarify:

• In CFF fonts, values should be set in both vmtx and VORG? Or use vmtx for glyf fonts and VORG for CFF fonts?

• In text you proposed earlier, you had This method is preferred, as it represents default behavior in vertical layout.. I gather what was meant was that vmtx is preferred over use of valt, and that this should still be mentioned? And does it mean that apps that use the vmtx table should never apply valt?

[kenlunde]

In CFF fonts, values should be set in both vmtx and VORG? Or use vmtx for glyf fonts and VORG for CFF fonts?

The former.

In text you proposed earlier, you had This method is preferred, as it represents default behavior in vertical layout.. I gather what was meant was that vmtx is preferred over use of valt, and that this should still be mentioned? And does it mean that apps that use the vmtx table should never apply valt?

Affirmative for both.

I am not aware of any fonts that currently include valt. Adobe's East Asian OpenType/CFF fonts were rebuilt approximately 20 years ago to prefer vmtx/VORG over valt. The advantage of vmtx/VORG treatment of these glyphs is that it represents default behavior in vertical layout, whereas valt requires the feature to be explicitly supported.

[PeterCon]

does it mean that apps that use the vmtx table should never apply valt? Actually, wouldn't it be better to state that fonts that include vmtx should not also support valt?

[PeterCon]

Proposed changes for the next version:

'valt':

Friendly name: Alternate Vertical Metrics

Registered by: Adobe (Modified by Adobe, this is the newer description)

Function: Repositions glyphs to visually center them within full-height metrics, for use in vertical setting. Typically applies to full-width Latin glyphs, which are aligned on a common horizontal baseline and not rotated when set vertically in CJKV fonts.Applies to full-width Latin, Greek, or Cyrillic glyphs, which are typically included in East Asian fonts, and whose glyphs are aligned on a common horizontal baseline and not rotated relative to the page or text frame.

Example: Applying this feature would shift a Roman h down, or y up, from their default full-width positions.

Recommended implementation: The font specifies alternate metrics for the original glyphs (GPOS lookup type 1, YPlacement).

Note: The same functionality can be accomplished by setting glyph vertical origins through the use of appropriate topSideBearing values in the 'vmtx' table and (only for fonts with CFF outlines) corresponding vertOriginY values in the 'VORG' table. This method is recommended as it provides the desired spacing for vertical layout by default. Fonts that include 'vmtx'/'VORG' tables should not implement this feature.

Application interface: For GIDs found in the 'valt' coverage table, the application passes the GIDs to the table and gets back positional adjustments retrieves positioning adjustment values from the table.

UI suggestion: This feature should be active by default in vertical-setting contexts.

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

Feature interaction: This feature is mutually exclusive with all other glyph-height features (e.g. 'vhal' and 'vpal'), which should be turned off when it’s applied. It deactivates the 'kern' feature.

'vhal':

Friendly name: Alternate Vertical Half Metrics

Registered by: Adobe

Function: RespacesRe-spaces glyphs designed to be set on full-em heights, fitting them onto half-em heights. This differs from 'valt', which repositions a glyph but does not affect its advance.

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, XPlacement, XAdvance, YPlacement and YAdvance).

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)retrieves positioning adjustment values from the table.

UI suggestion: In general, this feature should be off by default. Different behavior should be used, however, in applications that conform to Requirements for Japanese Text Layout (JLREQ) or similar CJK text-layout specifications that expect half-width forms of characters whose default glyphs are full-width. Such implementations should turn this feature on by default, or should selectively apply this feature to particular characters that require special treatment for CJK text-layout purposes, such as brackets, punctuation, and quotation marks.

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 this feature is applied. It deactivates the 'kern' feature. See also 'halt'.

'vpal':

Friendly name: Proportional Alternate Vertical Metrics

Registered by: Adobe

Function: RespacesRe-spaces glyphs designed to be set on full-em heights, fitting them onto individual (more or less proportional) vertical heights. This differs from 'valt' in that it does not substitute new glyphs (GPOS, not GSUB feature). The user may prefer the monospaced form, or may simply want to ensure that the glyph is well-fit., which repositions a glyph but does not affect its advance.

Example: The user may invoke this feature in a Japanese font to get Latin, Kanji, Kana or Symbol glyphs with the full-height design but individual metrics.

Recommended implementation: The font specifies alternate heights for the full-height glyphs (GPOS lookup type 1, XPlacement, XAdvance, YPlacement and YAdvance).

Application interface: For GIDs found in the 'vpal' coverage table, the application passes the GIDs to the table and gets back positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance)retrieves positioning adjustment values from the table.

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' and 'vhal'), which should be turned off when it’s applied. If 'vpal' is activated, there is no requirement that 'vkrn' must also be activated. If 'vkrn' is activated, 'vpal' must also be activated if it exists. See also 'palt'.