270914 - Reorder Arabic numbers as AN in Arabic text (lang="ar") even if not preceded by Arabic characters

Status: RESOLVED DUPLICATE of bug 151395

(Core :: Layout: Text and Fonts, enhancement)

Description

[Ahmad Gharbeia]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When a string of numbers and punctuation characters are in an HTML block is not
preceded with alphabet characters  it is not displayed in the right order, while
if any alphabet characters precede the string ordering is correct.

Reproducible: Always
Steps to Reproduce:
1.Viewd a web page that has dir="rtl" and <p>02:28 20-11-2004</p>
(or attached HTML file)

Actual Results:  
20-11-2004 02:28

Expected Results:  
2004-11-20 02:28

Comment 1

[Ahmad Gharbeia]

Attachment: HTML file containing bug-producing markup

Comment 2

[Uri Bernstein]

I think this is actually correct according to BiDi algorithm
(http://www.unicode.org/reports/tr9/):
Rule W2 says:

"W2. Search backwards from each instance of a European number until the first
strong type (R, L, AL, or sor) is found.  If an AL is found, change the type of
the European number to Arabic number."

In the first two paragraphs, no Arabic Letter (AL) is found before the digits,
so this rule does nothing. In the last two paragraphs, an AL is found, and the
type of the digits is therefore changd to "Arabic number" (AN).

The next phase involves resolving of the dash (-) in the date. The dash is a
European Seperator (ES). Rule W4 says:

"W4. A single European separator between two European numbers changes to a
European number. A single common separator between two numbers of the same type
changes to that type"

So in the first two paragraphs, where the ENs were not changed to ANs, this rule
applies and the type of the dash is changed to EN, creating an LTR run which
includes the digits and dashes. In the other two paragraphs, this does not
happen, and the dashes are later changed to "Other Neutral" (rule W6), and
eventually (rule N2) to the embedding direction, which in this case is RTL.

So IMO this bug is INVALID. But I'll leave it to the BiDi experts to make the
decision.

Comment 3

[Ahmad Gharbeia]

(In reply to comment #2)
> I think this is actually correct according to BiDi algorithm
> (http://www.unicode.org/reports/tr9/):

I cannot pretend to be a BiDi expert either, but Internet Explorer gets it right.
Besides, even if this behavior is by design (and IE is buggy), it's frustrating,
and the Bidi rules need to be changed.

Comment 4

[Simon Montagu :smontagu]

See rule HL2 of the Bidi algorithm [1]: "A higher-level process may reset
characters of type EN to AN or vice versa, and ignore W2. For example, style
sheet or markup information can be used within a span of text to override the
setting of EN text to be always be AN, or vice versa."

So this bug is not invalid, provided that the text is marked as Arabic (e.g. as
in the test case, with |xml:lang="ar"|). |dir="rtl"| is not sufficient, since
other right-to-left languages do not reorder groups of numbers in the same way
as Arabic. Since the algorithm only says "may", what we do now is not wrong, but
this is a valid and desirable RFE.


[1] http://www.unicode.org/reports/tr9/#HL2

Comment 5

[Uri Bernstein]

I just "discovered" bug 151395.
Simon - given your comments at bug 151395 comment 1 and here in comment 4, isn't
this a duplicate?

Comment 6

[Simon Montagu :smontagu]

At least I'm consistent :) Thanks for finding that, Uri.

*** This bug has been marked as a duplicate of 151395 ***