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

Hmm...I'm confused now.

> My root concern is about the behavior you're specifying for CSS, not
> about the definition of the Vertical Orientation property defined in
> Unicode.
> ...
> it has to do with unnecssary fallback behavior.
> ...

> Koji, you really need to better explain the need for allowing this
> optional behavior.

This optional behavior is what UTR#50 defines:
> Tr Same as Tu except that, as a fallback, the character can be displayed
> with the code chart glyph rotated 90 degrees clockwise.

So if you think this behavior is unnecessary, you need to feedback to UTC.
The members at UTC raised a concern because CSS does not allow the
behavior as defined in UTR#50. The need for allowing this optional
behavior is to allow an implementation that follows UTR#50.

I agree that the behavior to assume Tr as U is simpler to implement, and
still solves most of the cases, but it does not follow what UTR#50
defines. It's a tailoring of UTR#50. I'm happy to accept the tailoring,
but we should also accept UTR#50-compliant implementations.

But you still say there's nothing wrong with UTR#50. That's where I'm
confused. What did I miss?

/koji


On 9/25/13 1:46 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

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 05:03:43 UTC