W3C home > Mailing lists > Public > public-iri@w3.org > February 2004

RE: IRIs and bidi: Addition regarding higher-level protocols

From: Michel Suignard <michelsu@windows.microsoft.com>
Date: Wed, 11 Feb 2004 17:04:45 -0800
Message-ID: <84DD35E3DD87D5489AC42A59926DABE905D21B9C@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
To: "Martin Duerst" <duerst@w3.org>
Cc: <public-iri@w3.org>, "Mark Davis" <mark.davis@jtcsv.com>

Martin, here is my new proposed text (in quotes) for replacement ofn the
2nd paragraph of clause 4.1:

When rendered, bidirectional IRIs MUST be rendered using the Unicode
Bidirectional Algorithm [UNIV4] [UNI9] with an overall left-to-right
(ltr) direction. To achieve this, the IRI is embedded left-to-right in
all the following cases:
1. If the current embedding level before the IRI is odd (right-to-left)
2. If the last character with a strong directionality before the IRI is
3. If the first character with a strong directionality after the IRI is
No additional bidirectional rendering change by higher-level protocols
is allowed. 

Note: Embedding the IRI left-to-right can be achieved by embedding the
text with LRE...PDF. If the maximum allowed embedding level is exceded
(above 62), the IRI overall left-to-right direction may not be enforced.

The small diagramm (to be seen in monospaced chars) shows the desired

-String before-|  IRI  |-String after--
              L    ON   L
(For the string before and after, the IRI behaves as bidi 'ON') (For the
IRI itself, string before and after behave as bidi 'L')

BTW I am interpreting clause W2 of the Unicode Bidi algorithm concerning
the strong type enumeration as including as well the embedding
characters (at least the LRE) as it is necessary in the logic expressed
above. I have tried one of the sample bidi algorithm (Asmus Freytag
version) and it behaves that way.

Received on Wednesday, 11 February 2004 20:05:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:30 UTC