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

Thank you James. Your summary matches to my understanding, and it is quite good and helpful. Maybe I wanted it to be too short. Can you confirm, though his intention is different, as a result, it also means Unicode-compliant implementation will not be CSS-compliant? Or do you think I'm mistaken here?

For your a), I'm not positive to write algorithm in CSS spec. CSS defines behavior, and allows any algorithm. I understand that's the general rule of CSS WG, if I'm wrong, the WG will say so, so I'd like WG to discuss on this.

If it's too hard to figure out how to implement for someone, s/he does not have to. I agree with John that doing this for browser developer is not quite easy. However, UTR#50 defined in Unicode means that developers around the spec are also different; they're not WebKit or Gecko developers, but they're ICU, FreeType, harfbuzz, Skia, Cairo, or Qt developers. They would like UTR#50 to work not only in browser engines but also text labels too.

In not-so-far future, you might see a flag like this in your underlying engine:
  enum VerticalOrientation { mixed_utr50, upright, sideways_left, sideways_right };

With such underlying engine, it is troublesome if Unicode-compliant behavior is prohibited in CSS.

/koji

From: James Clark [mailto:jjc@jclark.com]
Sent: Sunday, September 29, 2013 1:52 PM
To: Koji Ishii
Cc: www-style@w3.org; CJK discussion (public-i18n-cjk@w3.org)
Subject: Re: [css3-writing-modes] Summary of Tr in UTR#50 and 'text-orientation' discussions

I would not state John's point 3 as "CSS should prohibit implementation of Tr as defined in UTR#50".  Rather I would state it as: with a font subsystem based on OpenType and with a font providing the 'vert' feature, the best approach is to say that it is up to the the font to implement UTR#50 correctly and the shaper should not try to work around any deficiencies in the font.  I think this would be a reasonable position for CSS to adopt.

The other position that I think it would be reasonable for CSS to adopt is to require implementations to check whether an OpenType font contains appropriate glyphs for Tr characters using the algorithm I have proposed or something similar.

I believe the current spec is unsatisfactory in two ways.

a)  It does not adequately specify how a UA should do this checking: with the complexities of OpenType -- notably contextual lookups and multiple features -- it is not at all obvious how to do it.  Leaving this under-specified will create interoperability problems.

b) Given that my proposed algorithm is not expensive either in terms of implementation complexity or runtime performance, there is insufficient justification for making this checking optional.

James

On Sep 28, 2013, at 8:30 PM, Koji Ishii <kojiishi@gluesoft.co.jp<mailto:kojiishi@gluesoft.co.jp>> wrote:

Since the discussion is long and complex, I'm making a summary of current discussions. I try short, accurate, and not-misleading, please point out if I'm not doing well.



John is making 3 different arguments in parallel:

1.     Tr in UTR#50 has technical issues. This should go to Unicode, not www-style.

2.     Tr impl costs is not worth to its value. Accepted. CSS now allows tailoring by re-defining Tr as U. The diff by this change is subtle.

3.     CSS should prohibit impl of Tr as defined in UTR#50 for consistency and simplicity. Disagreed, 1) we should allow any Unicode-compliant impl as CSS-compliant, 2) we acknowledged the diff is subtle in #2, and 3) UTR#50 impl is simpler under different architecture.



Some members of UTC requested that CSS should allow any Unicode-compliant impl as CSS-compliant.



Sylvain said as a matter of principle we should avoid optional behavior.



James Clark said, for the same reason as John's #3 and Sylvain, CSS should only allow UTR#50-compliant impl and disallow tailoring.



My preference is to allow both UTR#50 and the tailoring in John's #2. CSS already allows a lot of tailoring, such as Turkish uppercasing or UAX#14 grapheme cluster. As a secondary preference, if tailoring is really bad and that subtle consistency is critical, I'd agree with James.



I18N WG puts this topic on its agenda next week, I hope this clarifies the whole discussions and each position for I18N WG to discuss, and anyone else to jump in if s/he wants to.



/koji