Re: [css3-text] fullwidth punctuation kerning

On 1/5/2011 7:01 PM, Koji Ishii wrote:
> Table 3 is about line breaking, and it's covered by the 'line-break' property.

You are of course right, I carelessly cited from memory.  I meant the 
tables related to spacing, i.e. 2, 4-6 and 7.
> 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.

My bias comes from two considerations:

- I am primarily interested by HTML in the context of EPUB, where 
approximate typography is not enough and the target is traditional 
printed books

- I understand from my friends in the InDesign team that publishing 
houses in Japan all have different sets of typographic rules, and what 
we eventually need to give a rather complete control other the spacing, 
much like InDesign does. Essentially, an HTML document should be able to 
specify completely the normal spacing as well as the compression and 
expansion; in other words to override all the values in tables 2, 4-6 
and 7 JLREQ.

It seems to me that punctuation-trim gives access to only some of the 
entries in the tables (even ignoring ruby and similar that could go in 
other specs; e.g. hiragana/roman is still needed), and provides only a 
limited control to the alterations (for example, punctuation-trim speaks 
only about the "optimal" or "natural" spacing, but says nothing about 
compression/expansion).

I would prefer a design that allows for full control of all the entries 
in the tables. There could be shorthand notation to refer, e.g., to the 
values encapsulated in the tables of JLREQ (which fundamentally provide 
three sets of values).

>
> 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.

By "traditional Japanese typography", are you referring to e.g. metal 
type of 1900, to proprietary digital systems, or to (open) desktop 
publishing?

>   It is also different from almost all fonts in the market today; they are either full-width or variable-pitch.

What's in fonts is irrelevant for the purpose of writing the JLREQ or 
CSS. Those two are the mediation between document authors and layout 
engine implementers. What happens between layout engine implementers and 
font designers is regulated by other specs, and only the layout engine 
implementers have to deal with a potential disconnect.

>   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.

I don't see it that way at all. JLREQ is saying "we need to be able to 
request and achieve this layout" and CSS3 is saying "here is the syntax 
in CSS to express the request". It seems to me that everybody's life 
would be much easier if both JLREQ and CSS use the same conventions and 
the same vocabulary (and the choice of particular conventions/vocabulary 
is of secondary importance).


Eric.

Received on Friday, 7 January 2011 17:39:51 UTC