Erik and I discussed this (the advantage of sitting nearby). What we want is that label characters "stick" together, but also be delimited.<br><br>Take the following sequence (where a-i are any characters of legal labels)<br>
<br><div style="margin-left: 40px;">abc.def/ghi<br></div><br>It would be ok to have arbitrary reordering of letters between delimiters, and arbitrary ordering of whole labels and delimiters, eg:<br><br><div style="margin-left: 40px;">
gih/dfe.bac<br></div><br>but not <br><div style="margin-left: 40px;">gihd/fe.bac<br></div>nor<br><div style="margin-left: 40px;">egih/df.bac<br></div>nor<br><div style="margin-left: 40px;">egih/bacdfe.<br></div><br>So how about the following language:<br>
<br><div style="margin-left: 40px;">If the string formed by concatenating S1, D1, L, D2, S2 is subject to bidi reordering, then in the reordered string:<br><ol><li>each character of L will not be adjacent to any character of S1 or S2,<br>
</li><li>D1 and D2 will not occur between any two characters of L.</li></ol></div>(This is just on one of the issues -- will respond to Harald's other remarks.)<br><br>Mark<br><br>On Mon, Mar 3, 2008 at 12:43 PM, Erik van der Poel <<a href="mailto:erikv@google.com">erikv@google.com</a>> wrote:<br>
> > >> o No two labels, when presented in display order, should have the<br>> > >> same sequence of characters without also having the same sequence<br>> > >> of characters in network order. (This is the criterion that is<br>
> > >> explicit in RFC 3454).<br>> > ><br>> > > The above needs to be qualified, by adding something like "in the same<br>> > > bidi context". That is, as pointed out below, if you change the embedding<br>
> > > context, 123-456 in one context may look like 456-123 in another; same<br>> > > for abc.ABC and ABC.abc.<br>> ><br>> > Erik, did you verify this within one context, or between contexts?<br>
> <br>> I verified it for both contexts, each time within that one context.<br>> I.e. two hash tables, one for each context. I checked whether each<br>> bidi reordered string was already in the hash table. If so, it would<br>
> complain; if not, it would add that string to the table.<br>> <br>> <br>> > > A label L satisfies the Label Grouping Condition when for any Delimiter<br>> > > Characters D1 and D2 and any other strings S1 and S2 (possibly of length<br>
> > > zero):<br>> > ><br>> > > If the string formed by concatenating S1, D1, L, D2, S2 is subject to<br>> > > bidi reordering,<br>> > > then all of the characters of L2 in the reordered string are between D1<br>
> > > and D2.<br>> > ><br>> > > - The bidi reordering of L1, D1, L, D2, L2 may result in D2 coming<br>> > > before D1<br>> > > - Because S1 is any string, the bidi algorithm may set the paragraph<br>
> > > direction for the string to either Right-To-Left or Left-To-Right; thus<br>> > > the reordering condition has to work in both bidi contexts.<br>> ><br>> > that indeed sounds better.<br>
> <br>> That isn't what I tested though. I only made sure the characters stay<br>> together. The label L might be at the beginning or end of the (bidi<br>> reordered) string. I don't know whether that occurs in the exhaustive<br>
> testing, but the test allows L to be at the beginning or end, not<br>> necessarily *between* D1 and D2.<br>> <br>> Erik<br>> <br><br><br><br>-- <br>Mark<br>