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

So you only want UTR#50-compliant implementation, correct? That's a new proposal.

So we have 3 proposals on the table:
1. Only allow UTR#50-compliant implementation (prohibit tailoring)
2. Only allow CSS-tailored implementation (prohibit UTR#50-compliant)
3. Allow both

My vote is #3. #1 and #2 can only win tiny consistency for a few trivial code points.

Note that CSS+UTR#50 is still not perfect. During the design of UTR#50, we recognized we cannot solve all issues with current fonts. So while UTR#50 tries maximum interoperability, fonts can easily break it by putting rotated glyphs to U/Tu code points, and we know some fonts do. Ken Lunde at Adobe is working on UTR#50-compliant fonts to put the final piece.

Compared to that consistency issue, the consistency issue between #1 and #2 is much smaller, and it will also be gone if users are using UTR#50-compliant fonts.

So as long as two implementers want, I'd like to allow both.

/koji

-----Original Message-----
From: James Clark [mailto:jjc@jclark.com] 
Sent: Friday, September 27, 2013 11:48 AM
To: John Daggett
Cc: Koji Ishii; W3C Style
Subject: Re: [css3-writing-modes] inconsistent handling of 'Tr' codepoints in 'text-orientation'

Hmm. I don't think I've explained myself clearly.  The scheme I am suggesting does not prevent use of contextual features nor does it involve fallback, optional or otherwise.  Let me try again.  There are two stages:

1. When a shaper first encounters a font used in a vertical writing mode and the font has the 'vert' feature, it  maps each of the 47 characters of type Tr to a glyph string of length 1 and then runs a list of GSUB lookups constructed from the 'locl' and 'vert' features.
For each Tr character, it stores a single SIDEWAYS flag, which is false if the lookups changed the glyph string and true otherwise.
Apart from this, the results of running these lookups are not used.

2. When you come to shape a vertical run of text in this font, Tr characters with the SIDEWAYS flag true are treated like R characters and Tr characters with the SIDEWAYS flag false are treated like U and Tu characters.  After that shaping happens as usual in its full generality. The shaping pipeline is run once. For each type of character, OpenType features (including contextually-dependent
features) can be freely used.

A final point: the spec needs to describe and require the behaviour in 1, so that font designers in the future can design their GSUB features to behave correctly with a shaper that implements 1.  (Actually I cannot think of a case where a reasonable font would not behave
correctly.)

I would also mention again that the Microsoft Indic specs are using a very similar technique: in effect dynamically reading character properties from a font.

I continue to believe that this is the best solution:

- it can be efficiently implemented with little complexity;
- there is no optional behaviour; all UAs will behave consistently
- it is completely conformant to UTR#50

> So that's what all this complexity boils down to -- fallback for these 
> two codepoints.  This doesn't seem like a worthwhile tradeoff, 
> especially given that the lack of vertical alternates in a font like 
> Kozuka Mincho, which includes over 20,000 glyphs, suggests that the 
> rotated form of these characters is not actually used a whole lot in 
> practice.

On a practical level, I think what this complexity (which is not much in my view) buys you is more assurance that it will work consistently with fonts that you have not tested and perhaps do not even know about.

On a less practical level, I think it is preferable for the spec to have a consistent position on what determines character orientation.
Is it the font or is it CSS+UTR#50?   With your proposal, in some
situations it will be CSS+UTR#50 determining the orientation, in other cases it will be the font determining the orientation.  With my proposal, it is always CSS+UTR#50.

James

Received on Saturday, 28 September 2013 05:40:36 UTC