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:
For non arabic speakers, can you please post a screenshot and a simplified testcase? Thanks
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.
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.
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
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. ***
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
Resolution: --- → WORKSFORME
i can still see this problem using 188.8.131.52 , Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20071025 Firefox/220.127.116.11 ! doesn't work for me , Windows XP, please re-open
The bug is fixed on the trunk, which will become Firefox 3. Firefox 18.104.22.168 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.
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.