It is hard to tell from your code, since it depends on what the evaluation of some of the subfunctions would yield.<br><br>I'll list instead a four test cases that you can check. I hasten to add that I haven't absolutely checked these yet.<br>
<pre><span style="background-color: rgb(255, 255, 153);">AN N AN → AN R AN</span><br style="background-color: rgb(255, 255, 153);"><span style="background-color: rgb(255, 255, 153);">R AN N EN → R AN R EN</span><br><span style="background-color: rgb(255, 255, 153);">R EN N AN → R EN R AN</span><br style="background-color: rgb(255, 255, 153);">
<span style="background-color: rgb(255, 255, 153);">R EN N EN → R EN R EN</span><br style="background-color: rgb(255, 255, 153);"></pre>That is, the N in each of these cases would change to R.<br><br>The first two rules are when you have a neutral between two Arabic-Indic digits. For example, if you have U+0668 + "!?" + U+0669, then the display ordering of those three should be<br>
<div style="margin-left: 40px;">U+0669 ! ? U+0668. <br></div>That is, ٨ followed by ! followed by ٩ should appear from right to left. In my emailer this works. From left to right I see the Arabic 9, then ? then !, then the Arabic 8.<br>
<br>٨!?٩<br><br>The latter two rules are in effect if an EN remains in the text, eg if an
English number follows an Arabic letter and W7 has not been evoked. The , a ج followed by 8 followed by ! followed by 9 should all appear RTL.<br><br>ج8!?9<br><br>That case fails in my emailer.<br><br><b>Background:</b><br>
<br>Here is the text: <a href="http://unicode.org/reports/tr9/#N1">http://unicode.org/reports/tr9/#N1</a><br><br>The issue is that the text says that AN and EN act like R, and then has a set of rules. Those rules don't explicitly list all of the combinations of R, EN, AN on both sides of an N. That would add a 4 more rules, those added in yellow below.<br>
<blockquote>
<pre>L N L → L L L<br>R N R → R R R<br>R N AN → R R AN<br>R N EN → R R EN<br>AN N R → AN R R<br><span style="background-color: rgb(255, 255, 153);">AN N AN → AN R AN</span><br style="background-color: rgb(255, 255, 153);">
<span style="background-color: rgb(255, 255, 153);">AN N EN → AN R EN</span><br style="background-color: rgb(255, 255, 153);">EN N R → EN R R<br><span style="background-color: rgb(255, 255, 153);">EN N AN → EN R AN</span><br style="background-color: rgb(255, 255, 153);">
<span style="background-color: rgb(255, 255, 153);">EN N EN → EN R EN</span><br style="background-color: rgb(255, 255, 153);"></pre>
</blockquote>
If someone interpreted the rules as being complete, then they would neglect to change neutrals into R in those 4 cases.<br><br><br>Mark<br>
<br><br><div class="gmail_quote">On Mon, Dec 15, 2008 at 11:39, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Mark Davis wrote:<br>
> Let me try to shed some light on this. In the Unicode bidi<br>
> subcommittee, there are four different items that have recently come<br>
> up regarding BIDI.<br>
><br>
> The first is just some editorial clarifying text, and has already been<br>
> discussed and approved by the UTC. This is not relevant to IDNA.<br>
><br>
> The others were too recent to have been considered by the UTC.<br>
><br>
> The second is regarding overriding mirroring for archaic scripts. This<br>
> is not relevant to IDNA.<br>
><br>
> The third only applies to the embedding/overriding codes, which are<br>
> not allowed in IDNs: RLE, LRE, RLO, LRO, and PDF. This is not relevant<br>
> to IDNA. /<br>
><br>
> /The last is relevant, and came up most recently. It is the following:<br>
><br>
> There is reasonable disagreement about what the meaning of a<br>
> particular rule (N1) is, with two possible interpretations. We know<br>
> the intent of the author, but the intent of the author is outweighed<br>
> by what the common practice is. That is, the UTC needs to be quite<br>
> conservative about changes to BIDI, and existing practice is the major<br>
> consideration. That requires determining, however, what the prevaling<br>
> practice is, so we're investigating that now.<br>
><br>
> The practical impact for IDNA is, I think, the following.<br>
><br>
> 1. As a part of investigating the common practice, we need to consider<br>
> whether we need to add additional constraints to what Harald has<br>
> devised. I see two possible approaches:<br>
><br>
</div>> 1. We can wait until the investigation is competed, and accomodate<br>
> the results;<br>
> 2. Alternatively, we can add constraints (if need be) that<br>
<div>> accomplish the goal no matter which of the two interpretations<br>
> of N1 is being used.<br>
><br>
><br>
> 2. We should add to the security considerations for bidi some<br>
> indication of the fact that while the bidi constraints are intended to<br>
> ensure "Character Grouping" and "Label Uniqueness" as much as<br>
> possible, they may not do so for certain cases:<br>
><br>
</div>> 1. If the label is adjacent to all-ASCII labels (the xxx.3com problem).<br>
> 2. If the particular implementation of the bidi algorithm deviates<br>
> from the standard.<br>
><br>
Mark,<br>
<br>
what are the 2 interpretations?<br>
<br>
FWIW, here's my (horribly inefficient) interpretation of N1:<br>
<br>
# 3.3.4 Resolving neutral types.<br>
# N1. A sequence of neutrals takes the direction of the surrounding...<br>
for my $ix (1..@typelist) {<br>
if (!has_direction($typelist[$ix])) {<br>
# find directional in the forward direction<br>
for my $ix2 ($ix+1..@typelist) {<br>
if (has_direction($typelist[$ix2])) {<br>
if (effective_direction($typelist[$ix2])<br>
eq effective_direction($typelist[$ix-1])) {<br>
$typelist[$ix] =<br>
effective_direction($typelist[$ix-1]);<br>
}<br>
last;<br>
}<br>
}<br>
}<br>
}<br>
<br>
I don't know what that counts as.<br>
<div><div></div><div><br>
Harald<br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>