RE: [css3-text] fullwidth punctuation kerning

Hi Eric,

Regarding the whether to honor kerning table in the font or not, the optimal answer would be if the font has kerning table entry for the pair of characters, it can be used over the engine's rules I think. This way, we can avoid cases like different font as you said. But before doing so, I'd like to verify that font vendors create the kerning table for that purpose. Otherwise, better fonts can result in worse result, again as you pointed out.

Regarding the set of characters to be in each classes, it's a good point. The current table is from 2003 CR, which was based on JIS X4051, and you're right that JLREQ has come up with different tables. I'd like to investigate what the differences are, and how to merge them considering backward compatibilities and impacts to other languages.

The last point was already covered I believe. Current spec is based on JIS X4051, which also defines rules based on assumption that all punctuation are halfwidth. To cope with the issue, we have calculated actual spacing in the result of JIS X4051, and came up with the current rules so that we can achieve the same results using the fullwidth fonts. If you see any different results, it'd be a bug in the spec and I'd love to know that.


Regards,
Koji Ishii

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Eric Muller
Sent: Wednesday, September 29, 2010 9:41 AM
To: John Daggett
Cc: www-style; www-font
Subject: Re: [css3-text] fullwidth punctuation kerning

> 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 01:33:50 UTC