Arabic letters are sometimes not displayed in connected forms. This doesn't always happen: for example attachment 246695 [details] in bug 361986 displays correctly, but http://arabic.cnn.com displays all in isolated forms.
Created attachment 253877 [details] Testcase It seems from this testcase that the bug doesn't occur when no font is specified or when the specified font is not available.
http://arabic.cnn.com/ displays correctly here, with identical display in both "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124pre) Gecko/20070203 BonEcho/126.96.36.199pre" (Build ID: 2007020304) and "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070131 SeaMonkey/1.5a" (Build ID: 2007013101). Ditto for attachment 253877 [details] (for non-readers of Arabic: the fact that the final 'م' meem of the first (rightmost) word "as-salaam" is not joined to the preceding 'لا' laam-alif is part of the joining rules of Arabic and thus no error; likewise the initial alif [vertical stroke] is also a non-joining letter). Notes: 1. This 20070131 build is the most recent Sm trunk build which loads on my SuSE 9.3 system (where libstdc++.so.6 is not available). "One of these days" I'll upgrade to openSUSE 10.2, so I'll be able to test new trunk builds again. 2. I have set non-default fonts for serif, sans-serif, etc., including for Arabic. I chose (of course) fonts present on my system. 3. I don't see any monospace font in attachment 253877 [details]. Here is how it displays in whichever monospace font you are using to display Bugzilla comments: السلام عليكم The above looks OK on my system too.
Those builds are both without Cairo and do not have this bug. The bug is fixed by attachment 253747 [details] [diff] [review] in bug 357637.
(In reply to comment #3) > Those builds are both without Cairo and do not have this bug. > > The bug is fixed by attachment 253747 [details] [diff] [review] in bug 357637. > Hm. This prodded me to do some research. On the Mozillazine KB I found a link to cairographics.org and a statement that "Gecko 1.9 uses Cairo". Not very enlightening. How would I know whether a given build (such as the Gecko-1.9a2pre Sm-1.5a build mentioned above) does or doesn't use Cairo? Nothing obvious in its about:buildconfig. (If you want to avoid spamming the bug you may reply by email.)
(In reply to comment #3) > The bug is fixed by attachment 253747 [details] [diff] [review] in bug 357637. Not quite right: the lines that didn't connect in the testcase now do connect, but the lines that did connect before, i.e. with no font specified, or with a font not available on my system, display in isolated forms.
(In reply to comment #1) > Created an attachment (id=253877) [details] > Testcase > > It seems from this testcase that the bug doesn't occur when no font is > specified or when the specified font is not available. > It's not as simple as that. I have finally succeeded to upgrade to openSUSE 10.2 so that I can load "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070210 SeaMonkey/1.5a" (Build ID: 2007021001), a Cairo build. The testcase uses the following fonts: 1) unspecified - displays OK 2) "Arabic Transparent" - not present on my system - OK 3) "Traditional Arabic" - not present - OK 4) "Tahoma" - not present - OK 5) "ae_Furat" - present - displays OK in ae_Furat 6) "ae_AlMohanad" - present - displays OK in ae_AlMohanad 7) "Arabic Newspaper" - present - only isolated glyphs My homepage http://users.skynet.be/antoine.mechelynck/index.htm displays only isolated glyphs. The corresponding CSS in the <HEAD> names a number of fonts, the first one found is again "Arabic Newspaper". Let's comment that line away. Now: - ae_Furat next to the photo displays with the correct shapes, and the vowels where they belong (bug 81367) but all characters are too widely spaced (even when unvocalized) giving the text a "disconnected" look. _ ae_Rasheeq on both sides of the counter displays almost OK, with one slight "disconnectedness" about exactly halfway through the right part. Interestingly enough, that "slight disconnectedness" is also present in Konqueror, which otherwise displays the text correctly.
Dupe of bug 361986?
Simon, is this bug still valid?
All the testcases display correctly for me now.