W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-text] fullwidth punctuation kerning

From: Behdad Esfahbod <behdad@behdad.org>
Date: Wed, 29 Sep 2010 00:52:35 -0400
Message-ID: <4CA2C613.1060207@behdad.org>
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...


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:49:48 UTC