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

On 10/14/2013 8:37 PM, MURATA Makoto wrote:
> 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.

(1) and (3) depend on how common a fallback scenario would have to be.
This applies even if you counter (3) with "it helps readers". Then the 
question
would be "how often and how much in the real world".

I had understood John's argument (3) not so much that it "confuses"
authors but that it makes it very complex to manage correctly as an author -
and (my interpolation) that incorrectly managing it could lead
to effects as bad as not having a fallback.

If I've followed this discussion correctly the situation is one
where behavior is "undefined" if the underlying rendering architecture/font
can't support it, and therefore you allow a fallback to mitigate that
(presumably until everyone's caught up).

Seems to me that a measure of "how bad" and "how probable" the
occurrences of such "undefined" behavior are in realistic scenarios
should figure into the discussion. John points out correctly that
fallbacks do have various kinds of costs in this instance, so one would
like to see them at the minimum offset, if not dwarfed by the expected 
benefits.

Is that the case here?

A./
>
> 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 
> <mailto: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