The 'vert' GPOS (not GSUB) feature

[Ken Lunde]

Peter,

The number of environments that support combining jamo is limited, and vertical typesetting of Korean is perhaps even more rare, especially when it includes combining jamo. In more ways than one, we are in somewhat uncharted territory, so sticking with the status quo might not be the right approach here.

As I stated in my reply to Jan, two environments already support a font that includes *both* a 'vert' GSUB feature and a 'vert' GPOS feature (ignoring what seems to be a bug in macOS's implementation). Furthermore, Adobe's tools correctly build such fonts as evidenced by the test font that I provided in the referenced URL.

I completely understand that some environments may not handle such fonts today, or even in the near future. That is completely okay, mainly because this behavior is currently broken in virtually all environments, and I prefer to think longer term. Baby steps.

So, for the longer term and to be somewhat point-blank, does anyone have any objection to modifying the 'vert' feature description, in terms of the "Recommended implementation" and "Application interface" sections, so as to not preclude parallel GPOS implementations, especially given that at least two environments support it?

Getting Adobe apps to support this, let alone getting them to support combining jamo, might be an uphill battle on my end, but my interest is more about building the fonts correctly. "If they build it, they will come."

BTW, the handling of U+20DD, U+3099, and U+309A in vertical writing also benefit from this approach. The latter two are for the kana script, and are for attaching the "dakuten" and "handakuten" annotations to arbitrary kana characters.

Regards...

-- Ken

> On Feb 13, 2017, at 11:55 AM, Peter Constable <petercon at microsoft.com> wrote:
> 
> 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
> 
>