The 'vert' GPOS (not GSUB) feature

[Peter Constable]

IIUC, the 'vert' feature has a long implementation history that includes use in implementations that otherwise do not support OpenType Layout processing generally in order to get desired glyph substitutions needed when laying out Japanese or Chinese text vertically - not Old Hangul. So, the recommended implementation of associating 'vert' with type 1 GSUB lookups is based on the fact that, in such implementations, that's the only kind of lookup that will get processed.

I haven't considered your example in detail; when working on Old Hangul support some years ago and spec'ing for our Font team how the OT Layout tables should be implemented, I recall working on some details for vertical layout, but I don't recall having these issues - though I also don't recall what testing in vertical layout was being done.


Peter

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com [mpeg-OTspec]
Sent: Saturday, February 11, 2017 5:25 PM
To: mpeg-OTspec at yahoogroups.com; opentype-list at indx.co.uk
Subject: [mpeg-OTspec] The 'vert' GPOS (not GSUB) feature



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20170213/e097743d/attachment.html>