word-internal tags force word-final shaping in Arabic

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
15 years ago
11 years ago

People

(Reporter: bulbul, Assigned: mkaply)

Tracking

(Blocks 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

Reporter

Description

15 years ago
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:
Assignee

Comment 1

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

Thanks
Reporter

Comment 2

15 years ago
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.
Reporter

Comment 3

15 years ago
Posted file 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.
Reporter

Comment 4

15 years ago
Changing summary to read:
   word-internal tags force word-final shaping in Arabic
Instead of:
   letter before final Arabic yaa' is also final
Summary: letter before final Arabic yaa' is also final → word-internal tags force word-final shaping in Arabic
Status: UNCONFIRMED → NEW
Ever confirmed: true
Seeing this on OS X => All/All.
OS: Windows XP → All
Hardware: PC → All
*** Bug 304523 has been marked as a duplicate of this bug. ***
Blocks: Persian
Blocks: 312436
There's some interesting information on this issue at http://blogs.msdn.com/michkap/archive/2005/12/19/505309.aspx and the comments.
This is now WORKSFORME on all platforms :)
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME

Comment 10

12 years ago
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
The bug is fixed on the trunk, which will become Firefox 3. Firefox 2.0.0.9 does not have the fix.
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).
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.
Hmmm, what about the possibility of fixing it with the existing nsTextFrame for the pre-Thebes code on the branch?
BTW, why is this bug marked as WORKSFORME and not FIXED?
(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.

Updated

11 years ago
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Duplicate of this bug: 391924
You need to log in before you can comment on or make changes to this bug.