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

Folks,

I have been wondering whether this debate is about factual
matters or subjective value judgement.  Here is my (rough)
understanding of John's argument.

(1) Since implementation costs are heavy, even optional
    fallback should be disallowed.

(2) Fallback lead to negative side effects.

(3) Optional fallback confuse authors.

I think that (1) is subjective.  In reply to (3), I guess that
others will say optional fallback help readers, and the
debate will go nowhere.  How do people feel about
"negative" side effects (2)?

Regards,
Makoto


2013/10/15 John Daggett <jdaggett@mozilla.com>

>
> 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.
>
>


-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto