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

On 9/30/13 10:20 AM, "John Daggett" <jdaggett@mozilla.com> wrote:

>
>Koji Ishii wrote:
>
>>> I do not think this is a good characterization of John's position.
>>> No one wants to prohibit 'Unicode-compliant implementations', as
>>> far as I can tell, nor is a 'fork of the Unicode spec' suggested.
>> 
>> I agree. My point is that, if we accept his proposal, although his
>> intention is different, it'll be in-compliant to Unicode as a
>> result. And John is not responding to that point.
>
>Koji, I've already responded to your claim that Unicode compliance
>somehow requires the behavior you've defined in the Writing Modes spec:
>
>http://lists.w3.org/Archives/Public/www-style/2013Sep/0714.html
>
>See the text under "More on UTR50, Unicode and CSS".  I've appended
>the same text at the end of this message.
>
>In short, I see no "compliance" issue here.  Unicode defined an
>*informative* character property that CSS is using to define layout
>engine behavior.

Ah, ok, thank you for pointing that out, I missed that part. So you're
saying, since this is UTR, not UAX, CSS can fork the behavior, correct?
It's true it's UTR, but the idea to make it to UAX sometime in future was
discussed. When that happens, the property will be a normative property. I
do not think it's a good idea to fork Unicode spec just because it's UTR.

>I'm not saying UTR50 is wrong nor do I feel the need
>for what you describe as "tailoring" here.  I'm not debating whether
>individual codepoints should be U, R, Tu, or Tr, I'm simply saying
>that I don't think implementing what is effectively OpenType feature
>fallback is a good idea, and I've detailed why I think that way in
>several previous posts [1], [2].

Unicode takes implementations into account, and OpenType and CSS are two
most important applications. If you don't think Tr is not a good idea for
OpenType, I'm suggesting you go to Unicode ML to discuss.

Why do you not like to discuss there? It's not single person I can try to
bring in to www-style. Tr appeared in UTR#50 revision #4[1] in April 2012,
and UTC as a group spent really a long time to review the spec. I don't
think asking whole UTC members to discuss on a Unicode spec at www-style
is a good idea.

My memory is a bit vague here, but revision #1 had SB instead of Tr.
Wasn't that fantasai, you, and me who said SB is too ambiguous and
requested to put Tr instead? Sorry in advance if I remember this
incorrectly.

>For vertical text, layout engines need to divide text into two basic
>categories: (1) upright runs laid out using vertical font metrics
>(i.e. using the *height* of glyphs) and default vertical features (e.g.
>'vert') and (2) rotated runs that are laid out using horizontal font
>metrics (i.e. using the *width* of glyphs) with default horizontal
>features and then placed on the line by rotating the coordinate
>system.

We're in consensus on this point, aren't we? You said this more than a
year ago, we added to the spec more than a year ago, so this is non-issue,
except that James is against the idea now.

>The optional behavior you've proposed for CSS is that user agents are
>allowed to add a third, hybrid category: upright runs that switch to
>rotated runs based on a complex fallback mechanism involving OpenType
>features.  From an authoring standpoint the optional part is not
>desirable at all, a point James Clark [3] and Sylvain [4] have also made.

James is against adding your proposed behavior and want to stick with
UTR#50 behavior, if I understand correctly. Do I misunderstand?

> 
>From an implementor viewpoint, adding complex fallback mechanisms need
>to be judged based on the value they supply.  Given that well-designed
>fonts already supply vertical alternates for the both 'Tu' and 'Tr'
>codepoints, I don't see the importance of having this fallback
>mechanism.

As I replied to James, browser developers don't have to. People working on
FreeType, harfbuzz, Skia, Cairo, or Qt are looking at UTR#50. Because
their API is used to render plain text as well, they might provide an API
which just does UTR#50. In such architecture, all browser developers need
to do is to split runs only when computed values of 'text-orientation'
change, and pass the value to the underlying APIs.

In that architecture, the behavior you requested will make browser code
more complicated. You need to split runs by Tr code points or not, and
re-define Tr as Tu.

Which costs more depends on what architecture you're building your browser
upon. Compliant to Unicode, and not to fork, is important because
underlying APIs will follow Unicode, and we're on such layered
architecture.

But on the other hand, if your underlying APIs do not provide such
capability today, I agree with you that it's not an easy work for browser
developers to do without changing underlying APIs. That's why I'm
proposing allowing both behavior makes the most sense.

>As Sylvain has noted, it would be helpful at this point to have more
>information about the implementors who feel it's important to have
>complex fallback for fonts that lack vertical alternates for 'Tr'
>codepoints. I don't see much value in arguing about Unicode compliance
>or the fine points of which codepoints are classified which way in
>UTR50.

Does the above paragraph give you what you requested here?

I'm seeing multiple times why your proposed behavior is important, but
we're in consensus on that point (except James,) and your proposal is
already in the spec for more than a year.

The point of discussion here is that, whether we want to prohibit
Unicode-compliant behavior or not, right? And since you said the diff is
subtle, I do not see any values of prohibiting Unicode-compliant behavior
and therefore require additional complex and slow code for different
architecture.

[1] http://www.unicode.org/reports/tr50/tr50-4.html

/koji

Received on Monday, 30 September 2013 05:48:52 UTC