Re: [css3-text] fullwidth punctuation kerning

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