[mpeg-OTspec] Vertical ligatures

[John Daggett]

David Lemon wrote:

>> ...But to make it so that the vertical ligatures don't end up in
>> horizontal text runs, the font supplies a set of "dummy" vertical
>> alternate glyphs for characters included in vertical ligatures. 
>> The vertical ligature is then defined in terms of these dummy
>> vertical alternate glyphs, such that when the 'vert' feature is
>> applied a vertical ligature results but not in the horizontal case
>> where 'vert' is not used.
> 
> Kazuraki has a different set of glyphs for horizontal and vertical
> setting because the layout model didn't allow us to define the
> different horizontal and vertical placement and advance widths.
> (Remember it's proportional in both directions.) The fact that the
> different GIDs enable it to apply layout features for different
> directions was simply a convenient side effect.

The unique proportional nature of Kazuraki makes it natural to use
distinct glyphs for both the vertical/horizontal case, allowing the
'vert' feature to sort things out.  But for standard CJK fonts, there
still remains a key problem here, namely that it's difficult to
disambiguate ligatures intended for horizontal runs versus those
intended for vertical runs.

>> Note the title of the Ryu Murakami novel "69" or the use of "Wi-Fi"
>> in the iPad article, if the book was named "59" instead and the
>> term "Wifi" used, both these examples with a standard OpenType
>> Japanese font (e.g. Hiragino or Kozuka families) would exhibit the
>> problem, the 'fi' ligature would appear since the 'liga' feature is
>> on by default. So this *isn't* pure theoretics.
> 
> As Suzuki-san noted, these examples show stacked monospaced Latin.
> Note that these glyphs (which are different GIDS from proportional
> Latin) would not have 'liga' lookups in the first place, because
> ligation and monospace are stylistically incompatible.

There isn't a proportional/monospaced distinction but rather two sets
of codepoints, the basic Latin range and their full-width equivalents
(i.e. u+ff21-ff5a). Working around the problem of unwanted default
ligatures in stacked Latin runs requires that an author know about
this problem explicitly and work around it by altering the codepoints
used in the content.  This workaround doesn't work for other scripts 
which lack full-width equivalents (e.g. consider stacked Cyrillic
instead of stacked Latin).

>>>  Indeed; we concluded that there was no real need to duplicate a
>>>  set of horizontal layout features for vertical use.
>> 
>> Can you explain vkrn?
> 
> Certainly. Kerning is a behavior that is generally needed in both
> horizontal and vertical text. Since most CJK fonts use the same
> glyphs for both directions, the only option we saw was to handle the
> different kerning values for different directions as separate layout
> features.

I think Eric is right, the situation here is exactly analogous to the
use of distinct features for horizontal/vertical kerning.

> That's a fine thing to do if/when necessary. But we didn't consider
> it necessary to define separate vertical layout features for
> everything in the registry. There's also a practical aspect; many
> applications pick & choose which layout features to support. If we
> overwhelmed them with dozens of vertical-only features it seemed
> likely that only a few would ever get widespread implementation.

Looping back to John Hudson's original post asking whether a vertical
version of the 'dlig' feature was necessary, I think the key here is
not necessarily to define a slew of vertical-only analogues features,
but a way to define distinct lookups for the vertical vs. horizontal
cases.  If that's not possible by adding lookup flags or additional
parameters such as a 'relative position' parameter, defining distinct
vertical analogues to default features would assure that default
behavior doesn't produce unwanted artefacts in stacked text runs.
Just as 'vkrn' is enabled instead of 'kern' in the vertical case, 
something like 'vlig' could be enabled instead of 'liga' and 'clig'.

I think it's also important to point out that OpenType layout is at an
inflection point in some regards.  It's no longer strictly something
for use within publishing applications, over the next year or two the
browsers used by the majority of web users will support OpenType
layout for both horizontal and vertical text runs.  And the side
effect of that is that EPUB docs will also use OpenType layout.  This
will radcially diversify the set of authors using OpenType features
and the combinations of scripts/fonts used. Which is why I think it's
important to iron out wrinkles like these.

Cheers,

John Daggett
Mozilla Japan