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

Koji Ishii wrote:

> Discussion at I18N WG went quite well and smooth. Addison and I
> confirmed that we support #1, and neither understands arguments for
> #2. It was an informal discussion in a conf call, not a WG
> resolution. I didn't ask for it because neither of us understands
> John's arguments quite well. I said I'll talk to John for further
> clarifications.

The I18N WG discussion was unfortunately not minuted, so I have no way
to understand what the other two I18N members on that call (Richard
and Addison) support and *why* they do.

This feature requires a tradeoff and those who support it need to do a
better job of describing the use cases that necessitate this fallback
behavior.  The only evidence presented so far seems to be general
statements like "better fallback is good for users", an argument that
ignores the negative side effects of this feature, both the added
complexity for user agents and the disruption of contextual features
across U-Tr and Tu-Tr boundaries.

In the discussion I had with Richard and Addison two weeks ago,
Addison said he would investigate whether Amazon had implemented this
sort of fallback or not.  It would be useful to understand if this
fallback was implemented and why, given that fonts typically handle Tr
codepoints via vertical alternates without using rotation as a
fallback.

> 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.
> 
> The current CSS Writing Modes Level 3 says #3:
>
> # For Tr characters, which are intended to be
> # either transformed or rotated sideways, the UA
> # may assume that appropriate glyphs for upright
> # typesetting are given in the font and render
> # them upright; alternately it may check for such
> # glyphs first, and fall back to typesetting them
> # sideways if the appropriate glyphs are missing.
> 
> UTR50 says #1:
>
> # Tr: Same as Tu except that, as a fallback, the
> # character can be displayed with the code chart
> # glyph rotated 90 degrees clockwise.

These two specs cover different aspects of this problem.  UTR50
defines the default orientation for a given codepoint, the Writing
Mode defines how layout engines should lay out vertical text.  UTR50
does not define normative behavior for OpenType layout, it simply
states that it is possible to use rotation to effectively create the
appropriate glyph for use in vertical text runs.  So the statement
"UTR50 says #1" is plainly incorrect.

> The offline discussion with John didn't go well. It was like, I
> didn't get his answers to my questions, and John repeatedly asked
> the same set of questions I answered, so I guess, answers were not
> resolving the original questions in both sides. He looks illogical
> to me and not responding to my questions, and probably I look the
> same to him.

It was a distressing conversation at a couple different levels.  While
the current Writing Modes spec implies *optional* fallback, you seem
to very strongly favor that this fallback behavior be *required*
behavior (i.e. option #1 above).  This means we're even farther away
from a resolution, not closer.

My viewpoint is that this fallback feature reflects a tradeoff and, on
balance, this feature doesn't seem worth it given that it only affects
a small number of codepoints in practice.  But you seem to want to
take an absolute position -- "If it's only for one codepoint like 〰
U+3030 WAVY DASH, I still want this feature" is what you told me. 
It's hard to argue with an absolute viewpoint when the world is full
of gray areas. :P

I think it's also unfortunate that you seem to be trying to play spec
games by using your status as an editor of both the Writing Modes and
UTR50 specs. Your response to my statement that "UTR50 doesn't define
normative behavior for OpenType layout" was especially troubling --
"What do you want it to say?  I can change it next month to whatever
is needed to make it required." That sort of implies to me that rather
than build some form of consensus within both the UTC and CSS WG,
you'd prefer to simply try to impose this requirement by fiat by
manipulating specs outside the CSS WG.

John Daggett

Received on Tuesday, 15 October 2013 03:08:04 UTC