Re: Need for Level Direction Mark

2011/9/14 Kent Karlsson <kent.karlsson14_at_telia.com>:
> Because that stability guarantee says "The Bidi_Class property values will
> not be further subdivided." I'm not too keen on the word "subdivided" here,
> but it (here) means there will be *no additions* to the set of values for
> the Bidi_class property. Not even for new characters.
>
> As far as I can tell, there is no restriction saying that the bidi algorithm
> cannot look at code points as well as bidi category values.

That's absolutely not the way I understand it, notably if you consider
the term "further", which references what was done before, where
subsets of characters that were listed in the same class have been
later partitioned into separate classes, before the policy was
adopted. I am not advocating changing the existing bidi classes
already assigned to characters, just that currently unassigned
characters are already outside of any one of these classes.

And how will you define what is an "implicit" LDM ? For example "1.2"
have two interpretations (a single number with a decimal separator,
fields of digits have a fixed relative order and the dot is part of
that number; or a notation of two distinct numbers in fields separated
by the dot, the fields being assumed to be displayed in the same
direction as the embedding paragraph). Same thing about "31/12" (is it
a date made of two fields to render in the embedding direction, or a
fraction whose operands must NOT commute ?)

As this is impossible to determine, I really think that in absence of
markup, the existing CS class between two numbers should ALWAYS resove
using the bidi class of these numbers (this means that "1.2" would
always be considered as a single number, and "31/12" would always be a
fraction).

To change this meaning (and the expected rendering order if the
embedding paragraph is RTL), there's only one way: isolate the numbers
in LRE..PDF, so that it prohibits the propagation of their strong
directionality to the separating character of class CS.

The whole sequence "LRE(number)PDF" then externally has a weak
direction, just like the surrounding CS characters, whitespaces, and
other punctuations, and all these runs will need to take their
direction from the embedding paragraph.
Received on Wed Sep 14 2011 - 12:11:51 CDT