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 Friday, 27 September 2013 02:48:50 UTC