- From: Eric Muller <emuller@adobe.com>
- Date: Tue, 28 Sep 2010 17:40:52 -0700
- To: John Daggett <jdaggett@mozilla.com>
- CC: www-style <www-style@w3.org>, www-font <www-font@w3.org>
> Section 7.3 of the CSS3 Text spec details a property that effectively > controls kerning on a small subset of CJK punctuation characters: > > http://dev.w3.org/csswg/css3-text/#punctuation-trim > > I don't quite see the necessity of of an author level property to > control this unless it's something that is really controlled at an > author level stylistically. In fact, supporting this in a browser > that uses an OpenType layout engine would effectively require > *undoing* layout based kerning information contained in fonts, > especially since the default is 'none'. The spacing behavior of East Asian text cannot be implemented via the OpenType kern feature, and in practice is not. Consider the first example and the case where the 〔 and the ( come from different fonts or are at different point size; the 'kern' feature will therefore not necessarily "see" both glyphs. Furthermore, the rules for aki behaviors are really style rules and vary from one place/user/document to another. You can already see in the JLREQ document three different sets of values, and a layout engine like InDesign offers a dozen or so built-in sets of values, and lets the user change them arbitrarily. This implies that nothing can be usefully be built in the fonts. The punctuation-trim property seems to me to be an attempt at codifying some aki behaviors. I would much prefer the full blown control, where the document can specify the aki between each pair of characters, including optimal width, minimal width, maximum width, priority for shrinking, priority for expansion (i.e. tables 2, 4-6 and 7 in the JLREQ). If you think that is too much, then I would drop down to the three sets of values defined in the JLREQ. In both cases, this should be driven by the character classes defined in JLREQ, rather than by the classes defined by punctuation-trim (you can achieve that by getting the JLREQ authors to change their definition...). There is a separate matter which is that any aki model comes with some conception of the normal width of a character. For example, the JLREQ model, just like the JIS X 4051 model, says that a bracket is a half width character (which is why their aki table say "*add* 1/2 em of aki between ideograph and open bracket"). On the other hand, the convention in the fonts is that the glyphs are fullwidth. Somehow, the layout has to "remove" the extra half em (or turn the model around and not add the 1/2 em aki); which means that the layout engine has to know which half to remove (the left half for opening brackets, the right half for closing brackets, or one quarter on each side for middle dots). That's a convention between the fonts and the layout engine. The problem that Ambrose mentioned is that not all fonts follow the same convention (in particular Chinese vs. Japanese fonts). But that problem is fundamentally orthogonal to the problem of control of the aki. Eric.
Received on Wednesday, 29 September 2010 00:52:52 UTC