Re: Need for Level Direction Mark

2011/9/17 Peter Edberg <pedberg_at_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).

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.
Received on Sat Sep 17 2011 - 15:00:24 CDT