[OpenType] The 'vert' GPOS (not GSUB) feature

[Ken Lunde]

Jan,

I very much appreciate the feedback.

I still believe that the 'vert' feature is still the right vehicle for the functionality that I describe, mainly because it should take effect when the writing mode is vertical. I don't see a need to register yet another feature for this. Of course, the "Recommended implementation" and "Application interface" sections of the 'vert' feature definition would need to be revised to indicate that both GSUB and GPOS are possible implementations.

At least two implementations already support a font that includes both a 'vert' GSUB and a 'vert' GPOS feature: HarfBuzz and macOS (and presumably iOS). (As an aside, macOS seems to have a bug whereby it is expecting a negative value for XPlacement, and the expected value is -920 which suggests an issue with setting the vertical origin for zero-width glyphs. I already reported this issue to Apple.)

For me, the question is really whether it is best to do as much as possible in the 'vmtx' table (#1 and #2) or do everything in the 'vert' GPOS feature. Both approaches represent default behavior for vertical writing, though one could argue that only the 'vmtx' table overrides represent default behavior, because the 'vert' feature needs to be invoked, though it is always invoked by default by apps that support vertical writing.

If anyone else has any ideas, such as a way to solve this issue without adding 738 glyphs to the font, I am all ears. Otherwise, I see 'vmtx' overrides + 'vert' GPOS or 'vert' GPOS as the best solutions.

Regards...

-- Ken

> On Feb 12, 2017, at 4:11 PM, Jan Bruns <ebay at abnuto.de> wrote:
> 
> Message from OpenType list:
> 
> 
> Hallo Ken,
> 
> firstoff let me tell you I'm just someone that recently
> implemented parts of the OpenType specs (including GSUB
> and GPOS handling) in a one man software project, so
> don't expect too much competence regarding your question.
> 
> I'm a bit surprised that you have complaints about GPOS
> features not being executed by some software.
> 
> GSUB+GPOS both have additional script and langsys
> subtables that describe which features the font expects
> to be be executed given a choice for a script/langsys.
> 
> So there's normally no forcing need for making use of
> special registered feature names, "only" good practice.
> It might be helpful in cases like an unclear situation
> about where to apply some specific handling (application
> internal processing vs. font-defined processing). For
> example, there may be old fonts that just assume to
> receive directly glyph mapped unicode streams and apply
> some processing that later on turns out to be much
> better implemented on application level. So if apps
> evolve to also implement that same processing, they
> have a chance to filter out that font-defined
> processing they're yet doing on their own.
> 
> To me, the idea you describe (about using GPOS to do
> rough layout steps) might be appropriate given the
> goal you want to achieve, but in no way sounds like
> it would be best described as a 'vert' feature (but
> keep in mind I reallly don't know anything about
> the script you're talking about). It sounds like
> either a way for a specific font to solve some
> font specific problem, or maybe like frequently
> encountered problem that asks to be assigned some
> registered feature name.
> 
> Gruss
> 
> Jan Bruns
> 
> 
> 
> 
> Am 12.02.2017 um 02:24 schrieb Ken Lunde :
>> Message from OpenType list:
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> List archive: http://www.indx.co.uk/biglistarchive/
>> List settings: http://www.indx.co.uk/biglistarchive/?mode=usersettings
>> 
>> subscribe: opentype-subscribe at indx.co.uk
>> unsubscribe: opentype-unsubscribe at indx.co.uk
>> messages: opentype-list at indx.co.uk
>> 
>> 
>> 
> 
> 
> 
> 
> List archive: http://www.indx.co.uk/biglistarchive/
> List settings: http://www.indx.co.uk/biglistarchive/?mode=usersettings
> 
> subscribe: opentype-subscribe at indx.co.uk
> unsubscribe: opentype-unsubscribe at indx.co.uk
> messages: opentype-list at indx.co.uk
> 
>