Re: Need for Level Direction Mark

I can give another example where there are ambiguities on how to
resolve the direction of characters other then CS.

Just look at this page on Wikisource (this is a paragraph in French
containing Hebrew words in a French enumeration, look at where the
comma separations are placed). Note that I'm not able to find a
working solution for correct display in Chrome (which incorrectly
implements LRE..PDF or RLE..PDF or the equivalent HTML dir="rtl"
attribute of spans of texts, mapped in CSS to bidi embedding).

http://fr.wikisource.org/wiki/Page:Diderot_-_Encyclopedie_1ere_edition_tome_1.djvu/96

If we can use a browser that already has problems in correctly
implementing the UBA, it will be even more difficult to convince
browser authors to make new adjustments if you change the behavior of
CS characters in the UBA...

But it will be far more easy to convince them to accept a new
character that uses one of the existing Bidi classes, even if the
character is superficially the same (but you'll get strong oppositions
from WG2 that will be hard to convince if you want to desunify some
characters with a duplicate encoding only for a distinct Bidi
property).

In my opinion, encoding the proposed

   ONE, TWO, LDM, SLASH, THREE, ONE

should render exactly the same thing as with existing controls in

   LRE, ONE, TWO, PDF, SLASH, LRE, THREE, ONE, PDF

for representing a contextually commutative date "12/31"; and for the
non-commutative fraction "12/31" you can protect the expected
direction of fields with

   LRE, ONE, TWO, SLASH, THREE, ONE, PDF

by including the slash within the embedded span, if the existing UBA
is correctly implemented. And it does not require any new character
(LDM, or a duplicate SLASH), or any new Bidi class, or changing the
UBA algorithm to treat CS characters specially.

Philippe.

2011/9/14 Kent Karlsson <kent.karlsson14_at_telia.com>:
>
> Den 2011-09-14 03:31, skrev "Philippe Verdy" <verdy_p_at_wanadoo.fr>:
>
>> 2011/9/13 Kent Karlsson <kent.karlsson14_at_telia.com>:
> ...
>>> for the new one, and to the paragraph bidi level for the three old ones). (I
>>> know, this would be a form of "option 1" in the PRI.)
>>
>> You can turn it as you want it is still a splitting of the bidi class
>> if you change the behavior of class S like this.
>
> I did write that it was a version of the PRIs "option 1"!
>
>> Onve again, if you
>> want to encode new characters, why would you restrict yourself to
>> reusing an existing bidi class just to break it?
Received on Wed Sep 14 2011 - 12:57:32 CDT