I can give another example where there are ambiguities on how to resolve the direction of characters other then CS.
Just look at this page on Wikisource (this is a paragraph in French containing Hebrew words in a French enumeration, look at where the comma separations are placed). Note that I'm not able to find a working solution for correct display in Chrome (which incorrectly implements LRE..PDF or RLE..PDF or the equivalent HTML dir="rtl" attribute of spans of texts, mapped in CSS to bidi embedding). http://fr.wikisource.org/wiki/Page:Diderot_-_Encyclopedie_1ere_edition_tome_1.djvu/96 If we can use a browser that already has problems in correctly implementing the UBA, it will be even more difficult to convince browser authors to make new adjustments if you change the behavior of CS characters in the UBA... But it will be far more easy to convince them to accept a new character that uses one of the existing Bidi classes, even if the character is superficially the same (but you'll get strong oppositions from WG2 that will be hard to convince if you want to desunify some characters with a duplicate encoding only for a distinct Bidi property). In my opinion, encoding the proposed ONE, TWO, LDM, SLASH, THREE, ONE should render exactly the same thing as with existing controls in LRE, ONE, TWO, PDF, SLASH, LRE, THREE, ONE, PDF for representing a contextually commutative date "12/31"; and for the non-commutative fraction "12/31" you can protect the expected direction of fields with LRE, ONE, TWO, SLASH, THREE, ONE, PDF by including the slash within the embedded span, if the existing UBA is correctly implemented. And it does not require any new character (LDM, or a duplicate SLASH), or any new Bidi class, or changing the UBA algorithm to treat CS characters specially. Philippe. 2011/9/14 Kent Karlsson <kent.karlsso...@telia.com>: > > Den 2011-09-14 03:31, skrev "Philippe Verdy" <verd...@wanadoo.fr>: > >> 2011/9/13 Kent Karlsson <kent.karlsso...@telia.com>: > ... >>> for the new one, and to the paragraph bidi level for the three old ones). (I >>> know, this would be a form of "option 1" in the PRI.) >> >> You can turn it as you want it is still a splitting of the bidi class >> if you change the behavior of class S like this. > > I did write that it was a version of the PRIs "option 1"! > >> Onve again, if you >> want to encode new characters, why would you restrict yourself to >> reusing an existing bidi class just to break it?
