RE: [css3-writing-modes] Character's intrinsic orientation

I’ve got reply from Toshi Kobayashi, the primary author of JLREQ. I understand he agrees with me, but here’s my translation of his reply.

JLREQ provides three options to typeset Latin characters and Arabic numbers.

l  Upright

l  Rotated sideways

l  Tate-tyu-yoko (the ‘text-combine’ property[1])

In general, proportional Latin characters and proportional Arabic numbers will be typeset by rotated sideways, but JLREQ does not define it as JLREQ character classes as it is editor’s choice to make it upright or tate-tyu-yoko.

Although JLREQ character classes are not defined for the purpose of determining whether to apply upright, sideways, or tate-tyu-yoko, if applications want to implement automatic tate-tyu-yoko algorithm, it may be useful. However, punctuation characters like hyphen, prefixes, or postfixes are even harder to determine and therefore I don’t think it’s not easy to determine this using JLREQ character classes.

So it sounds like it’s the right way to go to me to define CSS default rules using Unicode rules, and then allow authors to make them upright by applying text-orientation: upright[2] or text-tranform: fullwidth[3]. I hope this is also not too far from what you said, except that having author custom rules should be postponed.

I hope this clarifies your concerns.

[1] http://dev.w3.org/csswg/css3-writing-modes/#text-combine

[2] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation

[3] http://dev.w3.org/csswg/css3-text/#text-transform



Regards,
Koji

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Koji Ishii
Sent: Thursday, March 24, 2011 4:46 AM
To: Eric Muller
Cc: www-style@w3.org; CJK discussion (public-i18n-cjk@w3.org)
Subject: RE: [css3-writing-modes] Character's intrinsic orientation

Thank you for the feedback, Eric.

I’m still a strong believer that JLREQ classes cannot be used for this purpose. I’ll confirm this with the authors at JLTF to get back to you.

For making author control for which character fall into which classes, I think it’s an advanced feature that we do not want in level 3. Let’s have a default set, and then we can extend to have such controls in future if authors want. I had several meetings with Japanese publishers and designers but have never heard of such requests. It even doesn’t exist in InDesign. I’ll ask publishers and designers if anyone wants such controls in future interviews.

Regarding the EAW, the point is that, based on the list of expected behavior, the combination of Unicode Script Property and EAW did the work. The spec is active and is being maintained. We can ask Unicode folks to fix if it’s outdated, but it actually matched to my expected behavior and to the behavior of Word and InDesign. So it’s not matter of when it was defined, it produces the result Japanese/Chinese authors expect.

Regarding the PUA, as I said, it’s up to UA. If you want to use additional markup, you can use text-orientation: upright.


Regards,
Koji

From: Eric Muller [mailto:emuller@adobe.com]
Sent: Thursday, March 24, 2011 4:19 AM
To: Koji Ishii
Cc: www-style@w3.org; CJK discussion (public-i18n-cjk@w3.org)
Subject: Re: [css3-writing-modes] Character's intrinsic orientation

On 3/23/2011 11:05 AM, Koji Ishii wrote:

 Unfortunately, JLREQ classes is not comprehensive as you said, and is not for this purpose.

Just to be clear, what I said is that JLREQ does not provide rules to automatically classify character occurrences; the set of classes is fine (actually InDesign provides a slightly smaller granularity, e.g. distinguishes rounded from square open brackets).

"Not for this purpose" is not clear at all. It is true that JLREQ is extremely vague about what gets rotated, but if you search for occurrences of "rotated", I think you will agree that their point of view is that a fragment of text is either "japanese" or "western", and that in turn drives spacing decisions (rather explicitly described) and orientation decisions (far less described). A good example is 3.1.1, b, 2, note 3:

(note 3)

LEFT DOUBLE QUOTATION MARK "“" and RIGHT DOUBLE QUOTATION MARK "”" are exclusively for horizontal writing mode and not to be used in vertical writing mode. Also, LEFT SINGLE QUOTATION MARK "‘" and RIGHT SINGLE QUOTATION MARK "’" are exclusively for horizontal writing mode and not to be used in vertical writing mode. However, in vertical writing mode, when Western characters (cl-27) are composed rotated 90 degrees clockwise, these quotation marks are sometimes used.

The last sentence clearly ties character classes and orientation. That tie should probably not be a surprise.

There is also a more or less explicit tie with width (proportional vs. 1 em) (as can be seen in the remarks in the tables in appendix A).







So my first point is that the document author needs to

be able to explicitly control the classification of any

character occurrence.



Are you saying CSS should have a property so that authors can specify which code point is upright or rotated sideways?

What I said is expressed in the realm of requirements, not that of solutions. If you ask for solutions, I'd be tempted to go down the path of a property that specifies the class (in the sense of JLREQ Appendix A). Another approach is to allow the document author to override the built-in mapping from character code point to classes - gives less control since all the occurrences of a given code point will be treated the same.


I don't think it's easy to define, to use, and to implement.

I don't see why it would be any different from any other attribute, such as point size.


 I've never seen such products. Does InDesign support this?

Don't know.



That is the whole point of EAW;

I hear you, but I don't see any thing that changes my evaluation: the EAW property, as it has been defined so far, both in intent and in actual values, is not the right tool for 2011.






There are some cases where you need to rely on fonts, like PUA. If the font is end-user defined characters for CJK, they must be upright, but PUA can be used for other purposes, so we have no way other than relying on fonts.

You do: explicit markup.


Eric.