No, they behave differently in the algorithm. The algorithm was recast to only use properties, not character values. But you can get the same results, if you want, by not doing that. You can also use one of the 16 values in 4 bits to be an exception value:
byte result = getCurrentProperties(ch);
if (result != EXCEPTIONAL_BIDI) return result;
switch (ch) {
case '\u20xx': return BIDI_RLO;
...
}
John O'Conner wrote:
> I noticed that many new bidi categories are in the 3.0 spec. There are
> only a few that really get my attention:
> PDF, RLE, LRE, RLO, and LRO. Each of these have only one character that
> claims that property:
> PDF: U+202C
> RLE: U+202B
> LRE: U+202A
> RLO: U+202E
> LRO: U+202D
>
> These properties seem to uniquely identify with only a single character
> in the entire Unicode space...in fact the characters with these
> properties actually use the property as their name. In other words,
> U=202C's name is POP DIRECTIONAL FORMATTING. If this property is so
> tightly coupled with a specific character, why bother creating a special
> property in the first place? Why not simply assign these characters to
> existing bidi categories like BN or ON? Implementors have to handle
> these characters as "special characters" anyway...so why not just drop
> them into an existing category? Does BN or ON not fit these?
>
> -- John O'Conner
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:02 EDT