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

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.  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].

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.

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. 
>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 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.

Regards,

John Daggett

[1] http://lists.w3.org/Archives/Public/www-style/2013Sep/0731.html
[2] http://lists.w3.org/Archives/Public/www-style/2013Sep/0765.html
[3] http://lists.w3.org/Archives/Public/www-style/2013Sep/0830.html
[4] http://lists.w3.org/Archives/Public/www-style/2013Sep/0834.html

More on UTR50, Unicode and CSS:
http://lists.w3.org/Archives/Public/www-style/2013Sep/0714.html

> If you think they defined it poorly, and you want not only tailor
> UTR#50 but also want UTR#50-compliant implementations non-compliant
> to CSS, please talk to UTC. It's not me who defined UTR#50, it's
> UTC, so objections should go to the right people.

Koji, this is an informative property rather than a normative one, as
the conformance section of UTR50 quite clearly states.  It establishes
a reasonable default for vertical character orientation but applications
using this data are the ultimate arbiters of behavior, as noted in 
the conformance section of UTR50:

http://www.unicode.org/reports/tr50/tr50-11.html#conformance

# The property defined in this report is informative. The intent of
# this report is to provide, in the absence of other information, a
# reasonable way to determine the correct orientation of characters,
# but this behavior can be overridden by a higher-level protocol, such
# as through markup or by the preferences of a layout application.
# This default determination is defined in the accompanying data file,
# but in no way implies that the character is used only in that
# orientation. 

The Vertical Orientation property is an informative property and CSS
is using it as that.  There's no strict compliance requirement, nor do
I think what I'm proposing violates the spirit of the property as
defined.  I don't object to anything in the UTR50 spec, nor do I think
anything was done "poorly". I simply think CSS should use the data in
a practical and efficient manner.

Koji, if you disagree with what I'm suggesting we do in CSS I think
you need to justify it at a technical level rather than trying to
justify it only in terms of spec compliance.

Received on Monday, 30 September 2013 01:21:25 UTC