W3C home > Mailing lists > Public > www-international@w3.org > July to September 2008

Re: Weird bidi behavior?

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Thu, 28 Aug 2008 16:33:28 +0900
Message-Id: <6.0.0.20.2.20080828163004.08911620@localhost>
To: Matitiahu Allouche <matial@il.ibm.com>
Cc: www-international@w3.org

Hello Mati, others,

One more question: Is there a way to have an embedding
(or also an override) behave in the way that at least
I and Richard seem to have expected (i.e. just behaving
like a single character/object of the respective
directionality on the outside). Currently, it seems to
me that adding &lrm; (or &rlm; if rtl) before and after
might work, but I'm really not sure.

Regards,    Martin.


At 10:35 08/08/28, Martin Duerst wrote:
>Hello Mati,
>
>Many thanks for your very quick and precise answer.
>
>Thinking over dinner and breakfast (or some other similar
>occasions between my two work days), I started to suspect
>as much as you confirm below.
>
>At 07:22 08/08/28, Matitiahu Allouche wrote:
>
>>   Hello, Martin! 
>>
>>It seems to me that it is working as designed. 
>
>But would we be able to say that it works as intended?
>
>Of course, intent is difficult to capture, but my guess
>would be that to a large number of people, a LTR embedding
>is something very inherently and strongly LTR, and should
>therefore behave as such to the outside.
>
>Also, one could immagine that it would be desirable to
>have the following preservation property of the bidi
>algorithm: If a sequence of strong LTR characters
>(or, a sequence of characters displayed currently as
>LTR) is wrappend in an LTR embedding, the display order
>doesn't change (and of course, same for RTL). The current
>behavior clearly doesn't exhibit this preservation property.
>
>Do you (or anybody else) have any idea why the algorithm is
>designed this way? Was this aspect overlooked? Are there other
>considerations that justify this behavior? Would it be too
>difficult to describe an algorithm that exhibited the above
>preservation property? Is this case too rare in practice to
>be relevant?
>
>Regards,    Martin.
>
>
>>Case 1 has a default direction equals to LTR, meaning a paragraph embedding level equal to 0.  The Arabic words implicitly raise the level to 1 at their location.  Simple. 
>>
>>Case 2 starts similarly, i.e at embedding level 0.  The span with dir="ltr"  is equivalent to a LRE.  It raises the embedding level to the next even number, which is 2 (rule X3 of UAX #9).  The English words within the span will receive level 2, and the Arabic word will receive level 3 (rule I1). 
>>The Arabic word following the span is at level 1, like in case 1 (rule I1). 
>>So you have a span at level 2 immediately followed by an Arabic word at level 1.  The regular rules (L2) say that the span will be displayed on the right side of the Arabic word. 
>>
>>Is that clear?
>>
>>Shalom (Regards),  Mati
>>          Bidi Architect
>>          Globalization Center Of Competency - Bidirectional Scripts
>>          IBM Israel
>>          Phone: +972 2 5888802    Fax: +972 2 5870333    Mobile: +972 52 2554160
>>
>>
>>
>>Martin Duerst <duerst@it.aoyama.ac.jp> 
>>Sent by: www-international-request@w3.org 
>>
>>27/08/2008 13:44 
>>To
>>www-international@w3.org 
>>cc
>>Subject
>>Weird bidi behavior? 
>>
>>
>>
>>
>>
>>Can somebody explain the bidi behavior of Case 2 at
>>http://www.sw.it.aoyama.ac.jp/2008/pub/bidi-test.html ?
>>The only difference between Case 1 and Case 2 is that
>>Case 2 uses dir='ltr' on the green <span>.
>>
>>Regards,    Martin.
>>
>>
>>#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>>#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
>>
>
>#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp    


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp     
Received on Thursday, 28 August 2008 07:34:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:17:18 GMT