Re: [css3-writing-modes] Re-Summary of Tr in UTR#50 and text-orientation discussions

Makoto Murata wrote:

>> The discussion is about how the UA should render the Tr code points
>> that do not have vertical alternate glyphs, and there are 3 options
>> on board.
>>
>> 1. SHOULD|MUST render the fallback rotated sideways.
>> 2. MUST render the fallback upright.
>> 3. MAY render the fallback upright, or MAY render rotated sideways.
> 
> My two cents.  I like #1 and #3.  I am skeptical to #2, which
> prohibits the fallback rotated sideways.  I do not believe that
> fidelity by #2 is the most important thing.

I think this is a very poor way to frame the issue here, it focuses
purely on the fallback behavior of a particular subset of codepoints
without considering this in the context of author expectations about
orientation in general and how layout engines deal with orientation in
vertical text runs.

>From a layout engine perspective, the four values of the Vertical
Orientation property defined in UTR50 (U, Tu, Tr, R) boil down to just
two -- either upright or sideways (as reflected in section 5.1.2 of
the Writing Modes spec). What's being discussed here is a feature that
requires (1) runs of Tr codepoints be separated from runs containing
other upright codepoints (U and Tu) and (2) complex heuristics 
to infer whether a font has a vertical alternate or not for runs
of Tr codepoints.  A side-effect of this fallback handling is that
contextual substitutions and positioning across U-Tr or Tu-Tr
boundaries will be broken in the fallback case (see below for more
explanation).

Given that this fallback feature has non-trivial implementation cost
and negative side effects, we need to justify this fallback in terms
of real benefit to authors and users.  Fonts intended for use with
vertical text runs have traditionally handled this by including
vertical alternates for Tr codepoints.  

  *** So the net effect with most well-designed fonts is ***
  *** that only one or two codepoints are actually       ***
  *** affected by this fallback! [1]                     ***

Yes, there are fonts that lack vertical alternates for more Tr
codepoints [2] but these are fonts that are also missing vertical
alternates for Tu codepoints, so no matter what you won't be seeing
correct layout in all situations.  When seen in the context of actual
fonts, the benefits of this feature seem quite trivial.

The "optional" nature of this fallback as currently specified will
also lead to confusion for authors.  Authors already need to use
markup when the default orientation differs from what their content
requires.  For example, vertical text that contains runs of Latin text
such as "Every schoolgirl knows that 6 ÷ 3 = 2!" will require extra
markup to explicitly rotate the ÷ (U+00F7) which is classified as 'U'
by default.  If the behavior of the fallback varies across user agents
then authors may or may not catch the inconsistency, depending upon
which the combination of user agent and font they're using.  For a
very small set of Tr codepoints (e.g. 〰 U+3030 WAVY DASH) it seems
simpler for authors to understand the need to use explicit markup to
guarantee the desired orientation, just as they will need to
understand for codepoints such as ÷ (U+00F7).  Over time, as fonts
follow the UTR50 guidelines and include vertical alternates for all Tu
and Tr codepoints, the need for this markup (or fallback) will
disappear for Tr codepoints.

Those who feel allowing this fallback is a good thing need to
demonstrate more clearly why actual fonts and content justifies the
additional implementation cost and negative side effects on contextual
features that this optional fallback incurs.  There are tradeoffs here,
this isn't simply a case of more fallback == better as some have suggested.

Regards,

John Daggett

[1] details of Tr codepoint handling for standard fonts
http://lists.w3.org/Archives/Public/www-style/2013Sep/0501.html

[2] example of font with missing vertical alternates
http://lists.w3.org/Archives/Public/www-style/2013Oct/0008.html

Contextual features in vertical text runs
=========================================

Layout engines handle vertical text runs by breaking them into upright
runs, which are laid out with vertical metrics and vertical features,
and sideways runs which are laid out with horizontal metrics and
horizontal features.  OpenType layout allows for the substitution of a
given glyph or an adjustment in its position to be conditional upon
one or more preceding glyphs.  For example, this allows adjustments in
sequences of punctuation characters or special-case glyphs at the
start of a word. However, since vertical and horizontal runs are
fundamentally distinct, there's no way for contextual runs to extend
across upright/sideways runs. This limitation is simply a byproduct of
the OpenType horizontal/vertical modality, there's no way to wave a
magic wand and wish it away.

Received on Tuesday, 15 October 2013 01:52:54 UTC