[mpeg-OTspec] Re: The 'vert' GPOS (not GSUB) feature

Wed Feb 15 23:52:59 CET 2017

For what it’s worth, one of the structural issues that came up fairly early in the OpenType definition process has to do with these implementation recommendations. We started down the path of recommending what appeared to be the most obvious implementation – but a number of forward-looking people pointed out that there are nearly always cases that benefit from using alternate implementations. (An early example was the question of whether superiors and inferiors could/should be handled as GPOS instead of GSUB.)

I concur with the notion that it’s dangerous in principle to make implementation assumptions based on a layout feature name. Any competent engine should be looking at what actual lookups are called, and not jump to conclusions.

I agree with Peter’s concern about environments that present incomplete implementations specific to supporting a given script. But in the ‘vert’ case, I’d expect such setups would get the same result they get today, because they’d ignore the GPOS capabilities.

Thanks,
--
David Lemon
Sr Manager, Type Development
Adobe

From: "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>> on behalf of "Ken Lunde lunde at adobe.com<mailto:lunde at adobe.com> [mpeg-OTspec]" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Reply-To: Ken Lunde <lunde at adobe.com<mailto:lunde at adobe.com>>
Date: Wednesday, February 15, 2017 at 9:41 AM
To: "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>, "opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>" <opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>>
Subject: [mpeg-OTspec] Re: The 'vert' GPOS (not GSUB) feature

Peter,

I welcome this. This functionality has been broken for so long, and I'd like to at least address this in the Source Han Sans / Noto Sans CJK Version 2.000 update later this year, to deploy fonts with the appropriate table/feature settings.

BTW, I wrote this up in the latest CJK Type Blog article that I published earlier this morning, which includes links to the Source Han Sans and Noto Sans CJK, along with links to two font implementations:

  https://blogs.adobe.com/CCJKType/2017/02/to-gpos-or-not-to-gpos.html

Regards...

-- Ken

On Feb 13, 2017, at 9:17 PM, Peter Constable <petercon at microsoft.com<mailto:petercon at microsoft.com>> wrote:
Ken:

I would want time to evaluate implications of revising the ‘vert’ description before considering changes.

Peter

From: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com<mailto:lunde at adobe.com>[mpeg-OTspec]
Sent: Monday, February 13, 2017 7:45 PM
To: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>
Subject: [mpeg-OTspec] Re: The 'vert' GPOS (not GSUB) feature

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<mailto: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> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com<mailto:lunde at adobe.com>[mpeg-OTspec]
> Sent: Saturday, February 11, 2017 5:25 PM
> To: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; opentype-list at indx.co.uk<mailto: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
>
>

------------------------------------
Posted by: Ken Lunde <lunde at adobe.com<mailto:lunde at adobe.com>>
------------------------------------

------------------------------------

Yahoo Groups Links

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