Comments on bidi-04

[Erik van der Poel]

>  >> o No two labels, when presented in display order, should have the
>  >> same sequence of characters without also having the same sequence
>  >> of characters in network order. (This is the criterion that is
>  >> explicit in RFC 3454).
>  >
>  > The above needs to be qualified, by adding something like "in the same
>  > bidi context". That is, as pointed out below, if you change the embedding
>  > context, 123-456 in one context may look like 456-123 in another; same
>  > for abc.ABC and ABC.abc.
>
>  Erik, did you verify this within one context, or between contexts?

I verified it for both contexts, each time within that one context.
I.e. two hash tables, one for each context. I checked whether each
bidi reordered string was already in the hash table. If so, it would
complain; if not, it would add that string to the table.

>  > A label L satisfies the Label Grouping Condition when for any Delimiter
>  > Characters D1 and D2 and any other strings S1 and S2 (possibly of length
>  > zero):
>  >
>  > If the string formed by concatenating S1, D1, L, D2, S2 is subject to
>  > bidi reordering,
>  > then all of the characters of L2 in the reordered string are between D1
>  > and D2.
>  >
>  >   - The bidi reordering of L1, D1, L, D2, L2 may result in D2 coming
>  > before D1
>  >   - Because S1 is any string, the bidi algorithm may set the paragraph
>  > direction for the string to either Right-To-Left or Left-To-Right; thus
>  > the reordering condition has to work in both bidi contexts.
>
>  that indeed sounds better.

That isn't what I tested though. I only made sure the characters stay
together. The label L might be at the beginning or end of the (bidi
reordered) string. I don't know whether that occurs in the exhaustive
testing, but the test allows L to be at the beginning or end, not
necessarily *between* D1 and D2.

Erik