- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 24 Sep 2013 21:46:32 -0700 (PDT)
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- Cc: W3C Style <www-style@w3.org>
Koji Ishii wrote: > I'm not sure if I understand what your root concern is. If your > concern is how Unicode defines Tr value, please send your feedback > to Unicode. The PRI was over, but you can report your concerns to > the reporting form[1] anytime. I'm happy to be a liaison for UTC > here, but it's not appropriate to discuss whether a value definition > in Unicode is right or not in www-style. My root concern is about the behavior you're specifying for CSS, not about the definition of the Vertical Orientation property defined in Unicode. You've defined this as optional behavior when it shouldn't be and it represents unnecessary complexity. As I showed in my original email, for Japanese text we're talking about fallback behavior that affects a mere one or two codepoints. CJK fonts supply the necessary vertical alternates, there's no need to specify fallback behavior like this for these codepoints, either normatively or optionally. > I understand it's not easy to implement without changing harfbuzz > today if you're relying on harfbuzz. I'm very happy to allow such UA > to be compliant with CSS too. This doesn't have anything to do with harfbuzz or any other shaping engine, it has to do with unnecssary fallback behavior. I could get into the details of why "OpenType variants exist" logic is complex for *any* shaping engine but I think that obscures the fact that it's somewhat silly to be specifying fallback behavior for just a handful of codepoints like this. You're specifying something that affects default rendering behavior, it should not be unduly complex unless absolutely necessary. > If we like simplicity and want to allow implementers to use either > architecture, we need both sentences. Isn't this the most > appropriate and the simplest way to go? Hmmm. Making something optional doesn't make it simple. Allowing inconsistent rendering behavior across user agents is just bad, not simple. Authors are already going to need to be aware of default orientation, for example with symbols used both in upright and vertical text runs. Given that, the "simple" way is just to make Tr codepoints behave just like Tu codepoints. Authors can work around cases that don't match their content by specifying the orientation explicitly. Koji, you really need to better explain the need for allowing this optional behavior. You said in your last post that developers have asked you to allow this optional behavior. Could you explain more clearly under what conditions this is needed? What content rendered with what set of fonts makes this sort of fallback desirable? Regards, John Daggett
Received on Wednesday, 25 September 2013 04:46:59 UTC