1.70 KB, text/html
1.75 KB, patch
|Details | Diff | Splinter Review|
54.96 KB, image/png
66.75 KB, image/png
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 I have worked on an indo-pak arabic quranic font, that works fine in internet explorer, but when i open the web page in Firefox, the numbers of quranic digits stay outside the circle: Here is the comparison between ie8 and firefox 3 rc2: [img]http://i169.photobucket.com/albums/u218/arifkarim/a140.gif[/img] [img]http://i169.photobucket.com/albums/u218/arifkarim/a141.gif[/img] I am using the latest version of uniscribe on both browsers. All other complex features of this font are working better in firefox than any other competing web browsers :) This is the only buggy problem :( I hope u developers will fix this problem soon.... Note: these digits are defined as marks in opentype language, which firefox is unable to understand.... Plz solve this problem before release... thnx Reproducible: Always Steps to Reproduce: 1. U need to make sure Mozilla Firefox supports latest uniscribe, Thats All! 2. 3.
Assignee: nobody → smontagu
Component: General → Internationalization
Product: Firefox → Core
QA Contact: general → i18n
Summary: Arabic Font Problem!!!! → Arabic Font Problem
Is there a version of the font available for download for testing purposes? This sounds similar to bug 290775.
Depends on: 290775
In fact bug 290775 no longer occurs, but the testcase there just has the End of Ayah characters without digits, so it doesn't help for testing this bug. Can you attach a testcase?
Created attachment 325150 [details] Testcase I can confirm this using the SIL Scheherazade font from http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=ArabicFonts_Download. I added the hacks described at http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=arabicfonts#7f69be97 to the testcase, but they don't help.
This happens because the End of Ayah character is defined in Unicode <=5.0 with a Bidi character type of "AL" (Arabic Letter) and so is right-to-left, while the digits have a character type of "AN" (Arabic Number) and so are left-to-right. This makes us render them in separate text runs. The definitions are being changed in Unicode 5.1, so this should be fixed by bug 427350.
Status: UNCONFIRMED → NEW
Depends on: 427350
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Arabic Font Problem → Arabic digits are not enclosed in ARABIC NUMBER SIGN, ARABIC END OF AYAH, etc.
(In reply to comment #4) > This happens because the End of Ayah character is defined in Unicode <=5.0 with > a Bidi character type of "AL" (Arabic Letter) and so is right-to-left, while > the digits have a character type of "AN" (Arabic Number) and so are > left-to-right. This makes us render them in separate text runs. > The definitions are being changed in Unicode 5.1, so this should be fixed by > bug 427350. thnx Simon its good that u regenrated the problem using shehrazade font, actually i made my font on it...... but i need to inform u that the bug still exists even in the latest version of firefox: 3.1 Can u check if the problem is solved?
It's not solved yet, since it depends on bug 427350, which is not yet checked in (there is a patch awaiting review).
(In reply to comment #6) > It's not solved yet, since it depends on bug 427350, which is not yet checked > in (there is a patch awaiting review). so u think this patch will remove this problem? thnx again for ur kind help.........
I'm not 100% sure that it will be enough to solve the problem. After it's checked in, we may need an additional patch.
(In reply to comment #8) > I'm not 100% sure that it will be enough to solve the problem. After it's > checked in, we may need an additional patch. hmmm, a guy on this mozillazine forum thread says that this bug was reported in firefox 2, so it cannot be fixed in firefox 3 builds! is he right? http://forums.mozillazine.org/viewtopic.php?f=23&t=664795&p=4003805
I've reset the target milestone in bug 427350 to mozilla1.9.1.
Created attachment 351186 [details] Testcase (with typo fix)
Attachment #325150 - Attachment is obsolete: true
Created attachment 351188 [details] [diff] [review] Patch This works in Windows, half works in OS X (only the third line of the testcase works, which is the same as in Safari), and doesn't work at all in Linux. Maybe a bug in Pango? Ehsan, I'm asking you for review in case this conflicts in some way with your work on bug 441782
Attachment #351188 - Flags: review?
Attachment #351188 - Flags: review? → review?(ehsan.akhgari)
Comment on attachment 351188 [details] [diff] [review] Patch No, I don't think this conflicts with my work on bug 441782.
Attachment #351188 - Flags: review?(ehsan.akhgari) → review+
Jonathan, I just noticed that you are one of the developers of the Scheherazade font. Can you throw any light on why the testcase doesn't render correctly on Linux and OS X?
In brief, because of limitations of the shaping engines we're using. Note that although the 3rd line does the combination in Safari, the digits now read backwards (12 becomes 21) because of the override, so this isn't really a useful workaround. I'd guess the same is true with your patch (haven't tried it yet). When I was working on Scheherazade, we never did come up with a satisfactory way to make this work through ATSUI, except by hacky use of overrides and messing with the encoding order, so I'm not surprised at the results you're seeing. I'll be interested to see what happens with CoreText on Leopard.... that's close to being ready to try. Re Pango, it's simply not supported there, AFAIK.
Thnx to both Jonathan and Simon... Glad, finally a patch for Windows is working indeed. :). But I have a question: How do I use this patch? Also I wonder if this patch fix would be included in the future releases of Firefox?
Pushed as http://hg.mozilla.org/mozilla-central/rev/eff94ca7dcae. Arif, this will be in forthcoming nightly builds of Firefox and certainly in 3.2. I will also be asking approval to check it in to 3.1.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Comment on attachment 351188 [details] [diff] [review] Patch This is low-risk, and well-baked on trunk.
Attachment #351188 - Flags: approval1.9.1?
Comment on attachment 351188 [details] [diff] [review] Patch a191=beltzner
Attachment #351188 - Flags: approval1.9.1? → approval1.9.1+
Not sure if it is a regression or a different bug, but using Firefox 12 on Linux, the digits are not enclosed by the end of ayah mark on the three lines, and for other signs there are enclosed on the last line only. If I switch the font to Amiri, end of ayah works fine with the 1st two lines, but not the third, all others are broken. Since my font is using the same OpenType lookup for all the 4 signs, I expect there is something wrong with the Unicode characters properties.
As far as I remember, and judging by comment 12, comment 14 and comment 15, this never worked in Linux. My results are even worse than yours: with Amiri (version 0.102) the digits are enclosed by the end of ayah mark on the first two lines, but are displayed overlapping.
(In reply to Simon Montagu from comment #24) > My results are even worse than yours: with Amiri (version 0.102) the digits > are enclosed by the end of ayah mark on the first two lines, but are > displayed overlapping. That is a bug in the font, if you use v0.101 it should be fine.
If this is going through HarfBuzz, I expect it to be broken. Because HarfBuzz flips the Arabic run to RTL before processing OpenType features. Which apparently is not what fonts expect.
But, Behdad, since the digits and the mark are LTR there shouldn't be any flipping, no?
HarfBuzz knows that Arabic OpenType is supposed to be run on logical RTL glyph order. So when it sees LTR Arabic, it first flips it to RTL then applies OpenType. Which wouldn't work in this case...
OK, I understand that, what is puzzling me is the inconsistencies between end of ayah and other signs in Firefox, HarfBuzz’s command line tools give consistent results. Anyway, do you expect this to be changed soon? I now have a version of the font that works with HarfBuzz’s current behavior as well, if it will take time to change it.
Well, I'll fix it when I know how to do so without breaking LTR Arabic text. No idea right now.
You need to log in before you can comment on or make changes to this bug.