RE: CSS3 Text: Multi-Directional Scripts in Vertical Inline Progression

After further thoughts and more reading, I saw that, according to your
definition, 'upright' also plays with the embedding level. Isn't
sufficient to say that 'glyph-orientation-vertical: 0deg' sets all
glyphs as belonging to 'vertical scripts' and thus are treated as 'L'
direction if 'block-progression: rl' and 'R' if 'block-progression: lr'?
Which is the same as 'natural' for vertical scripts.

Then 'upright' is only useful to do specific magic on punctuation, but
otherwise is just a derived case from 'natural'.

Finally, your 'context' description is also omitting the horizontal flow
case. I saw in example of use in that page
http://www.damowmow.com/playground/www-style/images/zh-mongol128.png
pointed by your other document at
http://fantasai.tripod.com/www-style/2003/directions/.

Michel

-----Original Message-----
From: Michel Suignard [mailto:michelsu@windows.microsoft.com] 
Sent: Monday, March 24, 2003 4:31 PM
To: fantasai
Cc: www-style@w3.org
Subject: RE: CSS3 Text: Multi-Directional Scripts in Vertical Inline
Progression



Fantasai, many thanks for your new contribution. Many useful ideas, a
very brillant study. Just a part I don't agree with:

In the introduction [1] (The BIDI problem), there are examples of
upright (Chinese and latin) with a left-to-right block progression. The
normal 'block direction' of such a case is 'rtl' (top to bottom
physically), this means that L characters (as shown in the picture) go
top to bottom (through bidi reordering) when their glyph orientation is
-90deg clockwise, but if upright, no bidi reordering occurs so they will
flow with the normal block direction which is top to bottom (which is
the desired effect). Of course you can force a block direction to be
'ltr' which would get you in trouble as you demonstrate, but why do it
when simply using 'direction:rtl' on the block would avoid the issue.

To get upright characters, one could just use
'glyph-orientation-vertical: 0deg', but that won't do well for the
enclosing marks (parenthesis, brackets), so I could see the point of
using an 'upright' value to do the smart thing about these marks. Your
BIDI clarifications concerning non upright fragments are very valuable
and should be added for both the '0deg' and 'upright' cases.

The new case which is really fascinating is the 'context' orientation.
In previous discussions, some of us had thought it may exist, but w/o
evidence it was difficult to take it into account. (I had seen as a case
study in a paper written about Mongolian layout, but not in a real
document). It could be added as a new keyword to both
glyph-orientation-horizontal and glyph-orientation-vertical.

It took me a while to understand your text about 'natural' orientation
style. I think you capture nicely the case of 'vertical script'
directionality for the vertical block-progression. However I think you
are not giving enough details about the horizontal case
(block-progression: 'tb'). :

In that case, each Mongolian word will (should?) be displayed top to
bottom with each following word going on the right of the previous one
(I have seen that layout in mixed German/Mongolian litterature samples).
In that case each vertical fragment of the vertical script is by itself
a 'L' entity. For that to work you need a line-stacking-strategy
allowing these vertical fragments to expend the line height.

With this it probably make sense to say that
'glyph-orientation-vertical: auto' is the 'natural' orientation style
for vertical orientations and create a new
'glyph-orientation-horizontal: auto' to capture the concept in
horizontal orientations. (we could change the name from 'auto' to
something else, maybe even 'natural' or 'normal', I don't have strong
preference).

As I have already completely separated 'direction' and
'block-progression' in my current draft it is reasonably easy to add
these new concepts in the draft.

Michel

Ref[1]:
http://fantasai.tripod.com/www-style/2003/directions/vertical-bidi.html
And http://fantasai.tripod.com/www-style/2003/directions/

Received on Monday, 24 March 2003 21:35:25 UTC