RE: [css3-text] fullwidth punctuation kerning

Eric, thank you for sharing your concern with us.

Table 3 is about line breaking, and it's covered by the 'line-break' property. Table 4 and 5 are the one for the 'punctuation-trim' property. It has a little more than just punctuation as you said, like spacing for ruby and inline-notes, but I think they should go into their own specs.

If you remove rows/columns for ruby, inline-notes, and that are covered by the 'line-break' property and the 'text-justify' property, you will find that what left are all about punctuation. What I'm trying to do here is to cover the tables by using combination of these properties. These properties are separated because authors might want to control them separately, and unfortunately JLREQ doesn't tell such things because it is a requirement, not a spec. To have a property to control punctuation kerning is supported by people who writes JLREQ, and some word processors like MS Word has already implemented that way for more than a decade.

> Furthermore, it's takes a point of view that is contradictory
> with the JIS/JLREQ model of layout, which considers that
> brackets are half-width and that space is added in some contexts.

That's a very good point. As you pointed out, JIS/JLREQ chose to use an assumption that punctuation glyphs are half-width, and typography system adds spaces as needed. CSS3 Text chose an assumption that punctuation glyphs are full-width, and typography system removes spaces as needed. You can imagine that these two give you the same result.

JIS/JLREQ chose the method just because it was easier for them to write the document. It is a different method from traditional Japanese typography where all punctuation glyphs are full-width. It is also different from almost all fonts in the market today; they are either full-width or variable-pitch. JIS/JLTF knows that, it's just a convention to write the document easier.

JLREQ is a set of requirements, so implementers must understand the rules and transform them so that they are implementable using actual fonts. On the other hand, CSS3 Text is an implementable spec, so we can't take the same method as JIS/JLREQ took. CSS3 Text does the re-interpretation of JLREQ so that every browser vendor doesn't have to do that. If you look at the result, then you might find that the two are talking about exactly the same thing using different font system.

I personally don't understand how much using "all punctuation glyphs are half-width" system made the document easier to write. It makes the document harder to read, makes implementers harder to implement, and makes reviewers like you harder to review. I'm sorry about that. But it was almost 20 years ago when the discussion was done in JIS committee, I can't change that. I hope your understanding.


Regards,
Koji

-----Original Message-----
From: Eric Muller [mailto:emuller@adobe.com] 
Sent: Thursday, January 06, 2011 6:49 AM
To: Koji Ishii
Cc: John Daggett; www-style; www-font; Ambrose LI
Subject: Re: [css3-text] fullwidth punctuation kerning

On 12/14/2010 3:55 AM, Koji Ishii wrote:
> The description of the 'punctuation-trim' property[1] is now updated to resolve the issue John pointed out.
>

I remain skeptical that the punctuation-trim property is useful. It deals only with a few of the situations (i.e. on punctuation only) while there needs to be a way to control a lot more (e.g. to get to tables 3, 4, 5, 6 of JLREQ).

Furthermore, it's takes a point of view that is contradictory with the JIS/JLREQ model of layout, which considers that brackets are half-width and that space is added in some contexts.

Eric.

Received on Thursday, 6 January 2011 03:04:50 UTC