- From: Behdad Esfahbod <behdad@behdad.org>
- Date: Wed, 29 Sep 2010 00:52:35 -0400
- To: Eric Muller <emuller@adobe.com>
- CC: John Daggett <jdaggett@mozilla.com>, www-style <www-style@w3.org>, www-font <www-font@w3.org>
On 09/28/10 20:40, Eric Muller wrote: >> 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. To me it seems like you are trying to justify solving the (very real) problem of kerning / interaction across font boundaries at the CSS level. While I agree that this is a problem well worth solving, I'm not sure CSS is the right medium for this. To be honest, I don't have a solution to propose, but if this is so serious, I think there are obvious proposals that can be made to the OpenType mailing list (eg. lookups that deal partly with character codes instead of glyph codes...). Looking forward... behdad > 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 05:00:00 UTC