- From: Alex Danilo <alex@abbra.com>
- Date: Fri, 15 Jul 2011 11:25:20 +1000
- 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 UTC