2011/9/17 Peter Edberg <[email protected]>: > 2. Philippe Verdy suggests that the intent of LDM is to change the bidi class > of a CS such as '/' to match the bidi class of the preceding EN character. > Actually, the intent of LDM is to act like either LRM or RLM depending on the > direction associated with the current embedding level; it has nothing to do > with the class of any preceding character. Mr. Verdy also suggests that > instead of using LDM, the solution is to instead encode another '/' with bidi > class R. However, that is equivalent to using RLM before '/' and does not > solve the problem described.
Well, I was still not sure about the intent of this ambiguous LDM. But if the CS character should adopt the embedding direction to reorder the numeric fields that it separates, I still think that the best is to embed those numeric fields in RLE..PDF or LRE..PDF (you can choose them arbitrarily, independantly of the numeric characters used in those fields; or even if those fields contain letters such as an abbreviated month name, or a CJK telegraphic abbreviation for month numbers or year numbers; but if the content of the field contains itself some whitespaces or variable characters, the choice of LRE..PDF or RLE..PDF would not be without importance, for the inner presentation of the content of this field, but would still have no influence outside of the field). That's why I suggested that the CS separators (and in fact any other sepators, including "-" or "." or ":" commonly found as date/time field separators), would not be influenced by the resolved direction of the internal content of the RLE..PDF or LRE..PDF fields, which by themselves should still have neutral directionality on the outside. The whole sequence of these embedded fields and separators would still be directionaly neutral, so that they will adopt the direction of the context where the full sequence is inserted. Using RLE..PDF and LRE..PDF solves all ambiguities, and requires no additional Bidi classes to be encoded (or even "implied"), and requires no new Bidi control. But it requires some enforcements of rules in the UBA algorithm. It provides the safest solution. Note also that there's no way to specify a weak direction for the internal content of embedded fields, as we don't have the WDE..PDF mechanism described in the UBA for now (but may be we could emulate it using RLE,B..PDF or LRE,B..PDF (but with which B character ?). And I also spoke about interlinear annotations (whose equivalent in HTML is the ruby notation, and in CSS the abolutely positionned blocks with "display:inline-block;position:absolute") which suffer the same problem in the UBA (note that ruby notations are frequently used to insert interlinear translitterations into a different script that may have a different direction than the script used in the annotated text). -- Philippe.
