- From: James Clark <jjc@jclark.com>
- Date: Fri, 27 Sep 2013 11:48:24 +0900
- To: John Daggett <jdaggett@mozilla.com>
- Cc: Koji Ishii <kojiishi@gluesoft.co.jp>, W3C Style <www-style@w3.org>
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