RE: [css3-text] fullwidth punctuation kerning

Well, I understand your concern.

Historically, if you draw boundaries between font designing and typesetting, this has fallen into typesetting category in East Asia.

When East Asia imported typesetting technologies, the closest word to translate it was "kerning" and it was the easiest for the non-East Asian to understand what it does, so we call it "kerning" in English today.

But still the concept falls into typesetting category, and thus I've never seen any font designers who want to put this rules into the kerning tables (at least as of now, please correct me if I'm wrong), and it is still believed that the responsibility is typesetter's rather than font designer's.

I understand "kerning by typesetting engine" could sound strange because defining kerning table is font designer's responsibility. But the reality is "something, that is specific to East Asia, and that is probably best described as kerning if you try to find the closest word in English" is typesetters' responsibility.

Since it's either author or typesetter who defines its behavior, not font designer, I think that kind of something should be implemented in CSS rather than OpenType.


Regards,
Koji Ishii

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Behdad Esfahbod
Sent: Wednesday, September 29, 2010 1:53 PM
To: Eric Muller
Cc: John Daggett; www-style; www-font
Subject: 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:26:56 UTC