Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

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