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

I support #1 if it says SHOULD, but oppose if it says MUST. I could also
accept #3. I'm opposed to #2.

My conclusion is based on an implementation strategy where:

(1) UA primarily delegates this substitution to the application of the
font's substitution rules;
(2) some UAs *may* choose to attempt to determine if font's substitution
rules did perform substitution, and, if not, perform it directly in UA by
implementing a UA based substitution;

I am not overly concerned with interoperability; however, if after a few
years of implementation experience it is found that all implementations use
the same approach, then the language could be upgraded to mandate that
common approach.

At this point, it would be premature to mandate a single approach.



On Fri, Oct 11, 2013 at 11:56 PM, Koji Ishii <kojiishi@gluesoft.co.jp>wrote:

> > Note that I failed to talk with i18n last week since I wasn't aware of
> the summer time
> > change. I'll do that next week, and John proposed us two to talk next
> week. Hope we have
> > better mutual understanding after that.
>
> I discussed at I18N WG, and then had an offline discussion with John. In
> short, the former went well, while the latter did not.
>
> Allow me to re-summary the discussion points. Hope this is better wordings
> thanks to John and Sylvain previous feedback.
>
> 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.
> I'm not sure if John and Sylvain agree with me on this point or not though.
>
> Within the W3C discussion, Addison, James, Murakami-san, and I support #1.
> It wasn't clearly confirmed if all are fine with #3 too; at least James and
> I said fine with #3.
>
> John and Sylvain want #2, and are strongly against #1 and #3.
>
> I hear #1 from UTC members and relevant people, John said he hears from
> his friends at UTC that nobody at UTC cares and fine with #2.
>
> 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 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.
>
> We tried to figure out what the fundamental difference is. We tried to
> forget about points to convince the other, but to figure out the real
> discussion points that can change the conclusion. It didn't work well
> either. I tried to tell that to him, but not sure if he understood it. I
> asked this a couple of times but I could not get his answer, probably the
> conversation was just as mentioned above.
>
> After 1.5 hours of such discussions, we gave up to reach a consensus,
> unfortunately.
>
> Neither John nor I have good idea how we could move further. Any
> suggestions?
>
> p.s. John, I tried to describe as fair as possible, but if you see any
> incorrect wordings or possible biases in this summary, please point out.
>
> /koji
>
>