- From: Eric Muller <emuller@adobe.com>
- Date: Fri, 7 Jan 2011 09:39:12 -0800
- To: Koji Ishii <kojiishi@gluesoft.co.jp>
- CC: John Daggett <jdaggett@mozilla.com>, www-style <www-style@w3.org>, www-font <www-font@w3.org>, Ambrose LI <ambrose.li@gmail.com>
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:40:52 UTC