W3C home > Mailing lists > Public > public-i18n-cjk@w3.org > October to December 2013

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

From: Koji Ishii <kojiishi@gluesoft.co.jp>
Date: Tue, 15 Oct 2013 00:18:10 -0400
To: John Daggett <jdaggett@mozilla.com>, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
CC: "www-style@w3.org" <www-style@w3.org>, "CJK discussion (public-i18n-cjk@w3.org)" <public-i18n-cjk@w3.org>
Message-ID: <CE82EC03.43D13%kojiishi@gluesoft.co.jp>
On 10/15/13 10:52 AM, "John Daggett" <jdaggett@mozilla.com> wrote:

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

I think we tried all the discussions we could do and found ourselves not
reaching to consensus, and it's time to ask broader stakeholders opinions.
I understand you said above is "how we would like to approach," but I
still believe that I wrote fair and accurate summary of "what each side

If I didn't, can you please come up with one-liner of what you are

>Given that this fallback feature has non-trivial implementation cost
>and negative side effects,

We discussed this, and we were not in consensus on this point, right?
'dlig' support is much less important than rendering U+3030 for instance,
and can be easily fixed by fonts. Since there are only few fonts that use
'dlig' in vertical flow, it's much easier to fix them rather than fixing
all the fonts in the world to be compatible with UTR50.

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

Ken is working on designing UTR50-compatible fonts, and maybe legacy fonts
will be gone in, say, 5 or 10 years. The value of Tr is to make the
transition as smooth as possible. It looks to me that you're seeing only
at today's implementations and ideal future combination, and I'm seeing
transition from the current towards to 5-10 years feature. Maybe that's
the root of differences?

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

This is one of my questions not answered yet from my point of view; you
say "trivial," and also say "lead to confusion." If trivial, it should not
lead to confusion. What did I miss?

>Authors already need to use
>markup when the default orientation differs from what their content
>requires.  For example,

Yeah, I know. There are bigger issues than Tr fallback, and I'm working
with Japanese publishers to come up with a note for how to specify the
orientations properly. Tr fallback is one of such issues.

But that's irrelevant here. That does not seem to justify prohibiting the
fallback behavior as UTR50 defines is the right thing to do, at least to

Received on Tuesday, 15 October 2013 04:18:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:59:19 UTC