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.