[OpenType] [mpeg-OTspec] Vertical ligatures

[Levantovsky, Vladimir]

FYI - forwarding all missing emails to MPEG list

> -----Original Message-----
> From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of
> Ken Lunde
> Sent: Tuesday, May 01, 2012 12:14 PM
> To: multiple recipients of OpenType
> Subject: Re: [OpenType] [mpeg-OTspec] Vertical ligatures
> 
> Message from OpenType list:
> 
> 
> John D,
> 
> You wrote:
> 
> > 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.
> 
> Our standard OpenType Japanese fonts include glyphs for kana and kanji
> ligatures (U+33xx), and they all have distinct horizontal and vertical
> versions. These are not handled via the 'liga' GSUB feature, because
> they are not intended to be on by default. Instead, the 'dlig' GSUB
> feature is used. The 'dlig' GSUB feature produces only a horizontal
> ligature form, such as 株式会社 becoming ㍿ (U+337F). The vertical form
> of the ligature is then accessed via the 'vert' (and 'vrt2') GSUB
> feature. If the 'vert' GSUB feature is applied before the 'dlig' GSUB
> feature, no ligatures are formed.
> 
> Other than the "square" Latin ligatures (at the end of U+33xx), our
> standard Japanese fonts should include anything troublesome in this
> regard.
> 
> Kazuraki is indeed a special case. If there is a better way to
> implement its "intended to be on by default" hiragana ligatures that
> doesn't involve revising all known text engines to recognize a newly-
> registered layout feature, we're all ears. Actually, we're all ears
> regardless, because if there is a better way to do something that is
> relatively straight-forward to implement, that is a good thing.
> 
> Also, I am not sure whether this helps or hurst the discussion, but
> there was a time when the 'ccmp' GSUB feature was not broadly
> supported, so we were including the two-dozen or so substitutions of
> our Japanese fonts in both the 'ccmp' and 'liga' GSUB feature, with the
> understanding that if client supported the 'ccmp' GSUB feature, the
> same substitutions in the 'liga' GSUB feature would simply become no-
> ops. At the time, this seemed to be the appropriate thing to do. If
> this were being considered today, with broader support for the 'ccmp'
> GSUB feature, the outcome would have been different.
> 
> I should also point out that font development is tough, because there
> is a delicate balancing act between implementing a feature based on the
> current level of support in applications and implementing a feature
> with the hope that future applications (or future versions of existing
> applications) will support it. Some of the features are considered to
> be critical (such as Kazuraki's vertical ligatures), and some are
> simply nice-to-have. Also, unlike applications, fonts are not updated
> as regularly.
> 
> > 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).
> 
> The Cyrillic (and Greek) case would advocate the use of flags to
> indicate how to handle the glyphs. Western fonts are likely to include
> proportional-width versions that should be rotated 90 degrees in
> vertical writing mode, and (legacy) CJK fonts are likely to include
> full-width versions that should remain upright.
> 
> >>>> 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.
> 
> Eric is always right.
> 
> The distinction seems to be when a font includes distinct glyphs for
> horizontal and vertical writing directions, in which virtually every
> glyph has a horizontal and vertical version with Kazuraki being an
> implementation example, versus a large number of glyphs being shared
> for horizontal and vertical with standard Japanese fonts serving as
> implementation examples.
> 
> What may work for one type of font may not work for another. The fact
> that Kazuraki is a Japanese font is somewhat irrelevant. Its layout
> model, which is defined by the glyphs it includes, suggested that a
> different approach was necessary.
> 
> >> 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.
> 
> I understand what you're saying. At this inflection point, it is
> relatively easy for browser developers to add support for a newly-
> registered layout feature, such as 'vlig', because they are currently
> adding support for OpenType features, and adding support for one more
> is a relatively easy task. One concern, however, is dealing with older
> applications. Getting the word out is harder than one may think.
> 
> I certainly would not object to registering a 'vlig' GSUB feature, if
> it is deemed necessary by people much smarter than me.
> 
> -- Ken
> 
> 
> 
> 
> List archive: http://www.indx.co.uk/biglistarchive/
> 
> subscribe: opentype-migration-sub at indx.co.uk
> unsubscribe: opentype-migration-unsub at indx.co.uk
> messages: opentype-migration-list at indx.co.uk
>