236135 - word-internal tags force word-final shaping in Arabic

Status: RESOLVED WORKSFORME

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

Description

[Leston Buell]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

In all text using a particular font on this page
   <http://www.alkaheranews.gov.eg>
the letter before every final yaa' is incorrectly in final (that is,
left-non-joining) form. The page is rendered correctly by Internet Explorer.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Mike Kaply [:mkaply]]

For non arabic speakers, can you please post a screenshot and a simplified testcase?

Thanks

Comment 2

[Leston Buell]

I'll need some time to post the screenshots and testcase.

The offending page is written in FrontPage. It appears that for some reason,
FrontPage puts many instances of the letter yaa' in a span separate from that of
the surronding spans, like this: 

<span style="" dir="rtl" lang="AR-SA">OTHER ARABIC LETTERS</span><span style=""
dir="rtl" lang="AR-SA">YAA'</span><span style="" dir="rtl" lang="AR-SA">OTHER
ARABIC LETTERS</span>

Mozilla seems to interpret the end of such a span to be the end of a word.

There are some other cases on the page where the shaping is wrong even when the
preceding letter isn't a left-joiner. I'll look into those, as well, but they
probably all reduce to this span problem.

Comment 3

[Leston Buell]

Attachment: testcase

Attached is a testcase (which links to an image of the misrendering).

As noted in the testcase, this problem also occurs if we have other types of
tags inside the word. For example, if one letter of a word is underlined, it
will be incorrectly shaped as though it were word-final.

Comment 4

[Leston Buell]

Changing summary to read:
   word-internal tags force word-final shaping in Arabic
Instead of:
   letter before final Arabic yaa' is also final

Comment 5

[Uri Bernstein]

Seeing this on OS X => All/All.

Comment 6

[Uri Bernstein]

*** Bug 304523 has been marked as a duplicate of this bug. ***

Comment 7

[Simon Montagu :smontagu]

There's some interesting information on this issue at http://blogs.msdn.com/michkap/archive/2005/12/19/505309.aspx and the comments.

Comment 8

[Simon Montagu :smontagu]

This is now WORKSFORME on all platforms :)

Comment 9

[Simon Montagu :smontagu]

Attachment: Testcase based on michkap's blog post

Comment 10

[maysara]

i can still see this problem using 2.0.0.9 , Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9 ! doesn't work for me , Windows XP, please re-open

Comment 11

[Simon Montagu :smontagu]

The bug is fixed on the trunk, which will become Firefox 3. Firefox 2.0.0.9 does not have the fix.

Comment 12

[(no longer active)]

I couldn't find the exact patch for this bug on trunk, but can we get a fix for this in one of the 2.0.0.x releases of Firefox?  This is very nice to have for the branch because it affects XUL accesskeys (check out bug 404149).

Comment 13

[Simon Montagu :smontagu]

I'm afraid not. The fix for this can't really be separated out from the whole rewriting of nsTextFrame for Thebes, which is far too large a change to go into the branch.

Comment 14

[(no longer active)]

Hmmm, what about the possibility of fixing it with the existing nsTextFrame for the pre-Thebes code on the branch?

Comment 15

[(no longer active)]

BTW, why is this bug marked as WORKSFORME and not FIXED?

Comment 16

[Simon Montagu :smontagu]

(In reply to comment #14)
> Hmmm, what about the possibility of fixing it with the existing nsTextFrame for
> the pre-Thebes code on the branch?

I doubt if such a fix would be approved at this stage of the life-cycle of the branch, unless you can show that it's a security issue. There are many many improvements in international text rendering in the trunk that aren't fixed in the branch and probably never will be.

(In reply to comment #15)

> BTW, why is this bug marked as WORKSFORME and not FIXED?
 
Because I didn't take the time to search for and reference the specific checkin that fixed it.