Philippe, On Sep 17, 2011, at 12:54 PM, Philippe Verdy wrote:
> 2011/9/17 Peter Edberg <pedb...@apple.com>: >> 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). Yes, for the numeric date example, wrapping each of the numeric fields in, say, LRE..PDF does solve the problem; since embedding boundaries are treated as sol/eol, a neutral character such as '/' between embedding boundaries will take on the embedding direction. And the digits inside the embeddings will not interact for layout with letters outside the date. However, as you suggest, for a more complex example such as that in UAX #9 section 5.6, to obtain proper behavior, one would need to know the overall page direction in order to choose whether to wrap each text field in LRE..PDF or RLE..PDF. The whole point of LDM was to be able to create semi-structured elements such as the example in UAX #9 section 5.6 *without* knowing in advance the direction context in which the element would be used. > > 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 ?). Sorry, which section of the UBA are you referring to that describes WDE (Weak Direction Embedding)? Deborah Goldsmith has suggested a "native direction embedding" which is like LRE/RLE but uses the inferred primary direction of the embedded text. I will try to put together a proposal about this for the next UTC. > 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. - Peter E
