The 'vert' GPOS (not GSUB) feature

[Ken Lunde]

All,

The current "Recommended implementation" and "Application interface" of the 'vert' feature states that it is a single-substitution (type 1 lookup) GSUB feature:

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

However, I seem to have discovered a valid use case for a GPOS implementation of the 'vert' feature.

The Adobe-branded Source Han Sans and Google-branded Noto Sans CJK Pan-CJK fonts support combining jamo, whose implementation includes six variations of [L]eading consonants, two variations of [V]owels, and four variations of [T]railing consonants. There are a total of 1,638,750 possible sequences, broken down as 11,875 two-character (L+V) ones plus 1,626,875 three-character (L+V+T) ones.

In terms of the font implementation, three GSUB features, 'ljmo', 'vjmo', and 'tjmo', drive the substitutions, selecting the right combinations to form a square or rectangular syllable. The L glyphs are spacing, and the referenced fonts use a 920-unit horizontal advance. The V and T glyphs are non-spacing (zero horizontal advance), and their shapes are shifted 920 units to the left, meaning that they are to the left of X=0.

All of this works for horizontal writing, at least for implementations that support combining jamo via these three GSUB features.

The problem is vertical writing.

Three things need to be adjusted for the V and T glyphs in order for vertical writing to work correctly:

1) The glyphs need to be shifted 1000 units up.

2) The glyphs need to have a zero vertical advance.

3) The glyphs need to be shifted 460 units to the right (this is due to the zero horizontal advance, and the centering of the glyph's width on X=500 for the vertical origin).

The first two can be accomplished via 'vmtx' table overrides. The third one cannot, because X-axis adjustments are not possible in the 'vmtx' table.

I discovered that a 'vert' GPOS feature can be created by declaring a lookup that includes GPOS lookup type 1 positional adjustments (XPlacement, XAdvance, YPlacement and YAdvance), and XPlacement is set to 460 for the V and T glyphs.

Of course, I could implement #1 and #2 in the 'vert' GPOS feature via the YPlacement and YAdvance settings, but I figured that it might be best to do as much as possible in the 'vmtx' table, and use the 'GPOS' for anything else, meaning the X-axis adjustments. However, implementing all three things in the 'vert' GPOS feature via XPlacement, YPlacement and YAdvance might be cleaner.

A sample font that implements the above ('vmtx' table overrides and 'vert' GPOS feature) is available here:

  https://github.com/googlei18n/noto-cjk/issues/79#issuecomment-278802783

As far as Adobe apps are concerned, it seems that the 'vert' GPOS feature is ignored. This is not a big shock.

Does anyone have any comments or opinions about this?

For what it's worth, the number of combining V and T glyphs in the referenced fonts is 738, and adding separate vertical glyphs that are pre-shifted along the X-axis is non-starter, because the glyph set is full.

Regards...

-- Ken