W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [css3-writing-modes] bidi in vertical writing modes

From: Alex Danilo <alex@abbra.com>
Date: Fri, 15 Jul 2011 11:25:20 +1000
Message-Id: <8APCOL.BQ6LI7P8LML@abbra.com>
To: www-style@w3.org
Hi Fantasai,

--Original Message--:
><snip/>
>Firstly, it's UTN22, not UAX22. UTN22 is not a spec and it is not normative.
>As an implementer, you should not be using UTN22 for anything other than
>background information.

Thanks for the code review of my comment. I'm sorry if you take
offence. I was merely supporting the view that the (now removed)
references to BIDI for the layout were confusing to me when
trying to implement it.

Yes UTN22 is good background information, and IMO required reading
if you intend to implement what the writing modes spec. is saying.
There is background information in there that is not reproduced
in the W3C draft (and probably shouldn't be since it's too verbose
for a W3C spec.)

>> 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.
>
>The current working draft actually doesn't say anything about using context to determine
>the orientation of punctuation...

True.

I'll leave it to the other implementers to work out why I do that...

>> 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.
>
>Bidi should be fully handled by the current writing-modes draft. Please explain
>in what ways it is not.

Given that most of this is non-normative, and Appendix C is
non-normative but marked as "This section needs careful review."
your removal of the reference to BIDI in the context of vertical
typesetting seems sufficient.

The issue I _personally_ had was that in UTN22 (non-normative
of course) there is no clear description of how the mixture
of upright and rotated glyphs are laid out.

e.g. If you have mixed orientation, then the rotated glyphs
can be treated as 'text-orientation: right', the upright
glyphs as 'text-orientation: upright'.

The mappings for this mixed case are:

(text-orientation: right):
Map ttb and ltr to htl (high to low)
Map btt and rtl to lth (low to high)

(text-orientation: upright)
Map ttb, ltr and rtl to htl (high to low)
Map btt and to (sic) to lth (low to high)

Then run BIDI (UTN22 detailed description left out).

If you mix orientations in one vertical line, then which mapping do you use?
ltr -> htl & rtl -> lth or ltr and rtl->htl

If you choose the latter then all hell breaks loose, but of course you wouldn't
do that since the text is rotated. So if you choose the rotated or not characteristics
of the glyphs to choose mapping to htl/lth via script/full-width characteristics or
whatever you lose the LTR/RTL context.

This is merely an implementation detail that rears its ugly head if you try
to actually implement this as described. The fundamental problem with the
spec as described is that LTR and RTL characteristics of the glyph runs
must be identified by running UAX#9 on the character string _before_
decisions about rotation or upright placement are made.

The swapping part of the runs in UAX#9 is all that really needs to be used
for the vertical layout, so the references to BIDI served to  confuse the issue.

I don't know if that explanation makes sense but the main problem I had
in converting your English sentences into code that actually produced
correct results was to run BIDI as expected as the first pas to identify
the LTR/RTL runs and then use script etc. as Koji and others have said
and Appendix C describes to decide upright/rotation. The placement of
the runs themselves _does_ follow one and only one step in the BIDI
algorithm, namely the re-ording of placement of the runs.

I believe the ambiguous mappings in (again non-normative) UTN22
fail to handle the mixed orientation case which is what I thought the auto
typesetting algorithm was attempting to solve. 

I hope some of that makes sense.

Cheers,
Alex

>For your reference, the relevant sections are listed below:
>   http://dev.w3.org/csswg/css3-writing-modes/#text-direction
>   http://dev.w3.org/csswg/css3-writing-modes/#text-orientation
>   http://dev.w3.org/csswg/css3-writing-modes/#line-directions
>
>~fantasai
>
Received on Friday, 15 July 2011 01:25:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:42 GMT