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

Re: [css3-text] fullwidth punctuation kerning

From: Eric Muller <emuller@adobe.com>
Date: Tue, 28 Sep 2010 17:40:52 -0700
Message-ID: <4CA28B14.8000106@adobe.com>
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.

Received on Wednesday, 29 September 2010 00:52:52 UTC

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