RE: [css3-text] fullwidth punctuation kerning

Eric, thank you for your response.

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

I understand your points. Yes, I do hear the same thing from my friends working in publishing industry, and I know everyone there applause InDesign the best DTP software ever for Japanese typography.

I, however, still believe what current CSS3 Text provides is a good balance considering the following points:

* CSS3 Text is the first version of CSS that covers international text layout seriously. Even line breaking rules do not exist in CSS2, so I consider CSS3 Text is version 1 of Asian typography in CSS. I'd like it get out of the door as early as possible and extend in version 2 (which is probably CSS Text Level 4), rather than delaying version 1 by years.

* I'm talking to several folks in publishing houses, and all of them say exactly what you wrote for DTP. But they split if I ask about Web and EPUB. Some believe Web/EPUB needs the same level of controls in typography, while some believe the requirement will be different. Screens do not have equivalent resolution as papers. Fonts may be changed by reader apps, or if the user doesn't have the font. As long as the current spec covers a good range of Web/EPUB users, I like it shipping earlier by covering those people, and cover the rest in the next version.

* If you look at the line-break property for instance, you will also find that it doesn't allow authors to specify which characters to use. InDesign of course allows this as you must know. Even MS Word does this too. That says, again, we're working on version 1. CSS3 Text is only trying to cover cases where preset values can suffice, and printers/publishing houses have agreed that it's good enough as long as we can extend in future, and they prefer us to ship earlier.

All these say, you're completely right about the long term goals. It's just a matter of what CSS3 Text should cover, and what to be left for future. Fantasai and I worked with several folks in EPUB, printing companies, publishers, publishing houses, etc. and we have a good level of consensus about this. The more features, the later they can start using CSS3 Text, and they even don't have version 1. Actually this is based on their requests to ship earlier with less features than required for paper publishing.

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

Ah, sorry, I meant metal type. I'm old enough to say digital/desktop publishing is not traditional :)

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

I got your point, but that puts me in a difficult position. It was actually requested by some developers that they want to implement without fully understand what JLREQ says. It's a good reference when you want to learn further, but using the method JLREQ took makes such developers harder to implement, and here we're. Not every developer understands typography in the same level as people in Adobe does. You know, "easy to understand" varies by the level of readers, and this is first time I hear from developers saying JLREQ method is easy to understand. How can I suffice both?

As you must already understand, it's just a matter of saying "always remove the blank half of fullwidth, and then add it back in this and that case". I could add such note section to the spec, but I wonder how much useful it is, since experienced people like you must be able to figure it out anyway, and it may confuse other people.

Note that I don't see the relationship between JLREQ and CSS the way you do. JLREQ is clearly a very good documentation to learn about Japanese typography, but I'm doing researches to other parties in parallel with JLREQ. You could think JLREQ is a school text; you can learn things in wide coverage in a very well organized way, but if you graduate the school and start working, things get slightly different. CSS is trying to cover such cases as well. There was one such example recently about emphasis dots used with ruby[1]. Just a note, it is not the reason why I took different description than JLREQ here though.

[1] http://lists.w3.org/Archives/Public/www-style/2011Jan/0011.html



Regards,
Koji

Received on Friday, 7 January 2011 19:58:35 UTC