Re: [css3-writing-modes] transcript of text orientation discussion

Dear Style-istas,

	I've been following the evolution of these proposals quietly
and commend you all for very good work.

	At the same time I've been building an experimental implementation
of the writing-modes algorithms as put forward in the working drafts and
have a few comments to make re: bidi, confusion, script, shaping etc. inline:

--Original Message--:
><snip/>
>[jdaggett]
>I know that but if you put it in the context of bidi that's a much more complicated algorithm.  It seems like you obfuscate what you're doing, you don't make it clear.
>
>[Florian]
>Don't you need to say this is somewhat similar to?
>
>[jdaggett]
>That's fine, I have no problem with that but look at the leadoff description, it goes into all the bidi details.  Bidi is a much more complicated problem, there's direction involved whereas this seems much simpler.  

I concur.

There is much confusion referring to bidi here. Fantasai's attempt to map the code points
and rotation onto  the bidi logic is admirable and represents a lot of effort.

But at the same, time it fails to handle mixed orientation embedded text in a rotated setting.
In SVG we completely skirt the issue with vague wording saying something like "rotated
horizontal text in a vertical setting is laid out as if it were done horizontally then the line
is rotated in place" or something like that. What the intention there is that if you have
some Arabic/Hebrew or whatever embedded in Latin in a vertical line, then the BIDI
placement will handle correctly positioning the Arabic and Latin if you read the line
by rotating your head for that part.

The current proposal doesn't address that case at all, but refers to BIDI and that
is where it gets very confusing to an implementer.

Attempting to implement to the letter of the current working draft not only made my
head sore, but produced this comment in my source code (you can make of that
whatever you like):

/**
 *  Set the insertion position for the current box and
 *  take into account BIDI processing for ordering placement.
 *
 *  Note, this is assuming the UAX#22 mappings for RTL and LTR
 *  for the vertical right-to-left layout. If we are to support
 *  Ogham in here which goes BTT then the logic would be pretty
 *  much the same as for RTL. //ZZ extend for BTT.
 *  (UAX#22 skips over detail in regard to embedding level
 *  placement, so other sources need to be consulted to get
 *  the expected behaviour).
 *
 *  Importantly, UAX#22 says to do the mappings for the Scripts
 *  from UAX#24, map them and then run the BIDI algorithm to get
 *  ordering. That's misleading. The bulk of the BIDI algorithm
 *  is in resolving numbers, white-space etc. from the 19 UAX#9
 *  classifications to get an embedding level (even or odd). Then
 *  the glyph ordering gets swapped based on the embedding levels.
 *  In UAX#22 what is meant is that this last part of BIDI -
 *  namely swapping based on even/odd embedding be done in the
 *  vertical direction. So it's really only the final step in
 *  BIDI that needs to be done. _Very_ confusing!
 *
 *  i.e. LTR == TTB, RTL == BTT.
 */

This is from an implementer, and my last comment in the comment is "_Very_ confusing!"
and not as a result of reading the email threads on this list at all.

>[Florian]
>Somewhat simpler, I'm not sure I can go as far as "much simpler".  I think if you want to drop the introduction, that's fine but I think it only refers to bidi in the intro and after that you stop talking about bidi?
>
>[fantasai]
>Yeah, pretty much.
>
>[jdaggett]
>Right, but I just don't see the need, bidi has nesting behavior does it not?

Perhaps my code comment above clarifies what my interpretation of the working
draft and UAX specs. goes. I'm not saing I'm correct here, just trying to turn the
textual prose in the draft and annexes into working code.

><snip/>
>[stevez]
>So, yes, I don't agree that the current algorithm is what we want even if rewritten and secondly I think we need to answer the bigger questions of that John raised about treatment of full-width characters in general, the issue of whether we should be using codepoints in the decision at all, I was basically arguing for a script-based solution.  And there's one final one, which is I don't think shaped scripts should ever be upright.

I completely agree with this comment regarding shaped scripts.

><snip/>
>[stevez]
>As I understand the problem, we're trying to define the behavior of the default case i.e. No markup.  That you can't do experimentally.  There isn't any markup to control it.  

Yes indeed.

I'll quietly change my code as you guys change your minds.

But at the moment, if I see punctuation in a Latin context I let it inherit the script of the
identified surrounding text which determines it's orientation. That seems to be the
intention of the working draft and matches what a bunch of people have said on this
list in various emails. Funnily enough it produces good results.

Also, the code comment above is my personal interpretation and it also handles
mixing actual BIDI code-points in a rotated vertical setting, something that is
not addressed by the current writing-modes draft.

In SVG we have different properties for vertical setting and as far as I understand
we intend to adopt the CSS3 properties and change in SVG2 to align with CSS
better.

Hopefully a decent default behaviour can be agreed upon as this work shows
great promise.

Alex

Received on Thursday, 14 July 2011 00:57:17 UTC