Reported to me by a Yiddish user: the nightly build: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; rv:0.9+) Gecko/20010516 I find that the reversal looks good, but all the composing characters are separated from their base. For instance, the word "lomir" in the first text paragraph. The alef is separated from its HEBREW POINT QAMATS; they should be together.

Reassign to ftang.

katakai- it looks like GTK hebrew rendering issue. Can you take a look at it?

Prabhat, can you take this?

smontagu@il.ibm.com (Simon Montagu) on the netscape.public.mozilla.i18n newsgroup posted this > >= http://bugzilla.mozilla.org/show_bug.cgi?id=60546, right? > I dont personally agree, I think from the comments on 60546 that it is windows specific wheras this bug is on Sun/Solaris.

masaki, please assign it to me (am not able to reassign it to myself) prabhat.

Assign to prabhat.hegde@eng.sun.com.

Changing QA contact to giladehven@hotmail.com. Changing component to "Bidi..." and adding intl keyword. Gilad, can you confirm (reproduce) this problem? Thanks.

Marking NEW.

Copied from n.p.m.i18n: In spite of their otherwise good BIDI support, Mozilla 0.9.1 and 0.9.2 as well as the nightly build as of yesterday fail to display Hebrew diacritics in correct positions above letters if the CSS property TEXT-ALIGN is set to the value JUSTIFY, whether internally or externally, for an inline element containing the combination of Hebrew letters and diacritics. It took me a while to pin down this as the environment of the buggy display. ---------------------------------------------------------------- Tsuguya Sasaki, PhD E-mail: tsuguya@gol.com WWW: http://www2.gol.com/users/tsuguya/ ----------------------------------------------------------------

I'd attatch a sample of what Tsuguya is talking about, but Bugzilla currently wont let me. You can see it at http://mail.hlmm.com.au/diacritics.html If you have problems with this URL - contact me direct.

Is this a Unix only problem. Can we reproduce the same problem on window?

Mass-move all BiDi Hebrew and Arabic qa to me, zach@zachlipton.com. Thank you Gilad for your service to this component, and best of luck to you in the future. Sholom.

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

not really sure bug 117776 is a dup of this one. simon, can you put down a simplier test case for me ? (and attached to the bug) reassign back to ftang

reassign to smontagu as per ftang's comment

Related to Bug 60546?

Problem is not specific to Sun hardware, nor to Solaris per se; I'm getting exactly the same thing here on Mandrake 9.2 on x86. All nikkud pointings in rtl text display to the left of their consonants. This includes not just vowels but also other marks, such as dagesh and accent marks. I am not sufficiently empowered to change the hardware field from Sun to All, but I can confirm the issue on Linux/x86, with Firefox 0.9.3. See also this Wikipedia article, which can serve as a testcase and also has notes on where the marks should be positioned: http://en.wikipedia.org/wiki/Niqqud

updated per comment 19

Still here in Firefox 1.0 on Linux/x86. Please note that Qt renders nikkud (nearly) correctly even in simple text fields. Is there a way to borrow their ideas without license contamination? Perhaps a related issue is that some combining diacritics are rendered over the following character, instead of the preceding one. E.g. U+0300, U+0301, U+0304 are displayed incorrectly, while U+0302 and U+0304 are OK.

Please please please FIXIT! This begins to look embarrassing! It's year 2006 now and the bug is open since 2001. Mozilla and Firefox are two graphical application on my Linux desktop that doesn't display nikkud correctly. Most GTK and Qt application are able to do that.

I believe this is the same bug, or a near cognate: In Linux, but not in Windows, Firefox displays Arabic short vowels "between" consonants instead of "over" them. Using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060714 Firefox/1.5.0.5 - Build ID: 2006071404" See the Arabic part of the heading of http://users.belgacom.net/antoine.mechelynck/ as an example. (With recent Fx builds I get it every time under Linux, never under W32. Just browse to the above URI to see it.)

(In reply to comment #23) > I believe this is the same bug, or a near cognate: > > In Linux, but not in Windows, Firefox displays Arabic short vowels "between" > consonants instead of "over" them. > > Using "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gecko/20060714 > Firefox/1.5.0.5 - Build ID: 2006071404" > > See the Arabic part of the heading of > http://users.belgacom.net/antoine.mechelynck/ as an example. (With recent Fx > builds I get it every time under Linux, never under W32. Just browse to the > above URI to see it.) > Oops! Wrong URI! http://users.skynet.be/antoine.mechelynck/ is the right one. (but the wrong one has a <meta> to load the right one anyway.)

(In reply to comment #25) > Created an attachment (id=253243) [details] > testcase for Arabic (look at the Arabic text left of the photo) > Note: some images are missing but what matters is the text. I intentionally added both "good" and "bad" screenshots so people can compare regardless of how their version of Gecko renders it on their platform.

(In reply to comment #23) > In Linux, but not in Windows, Firefox displays Arabic short vowels "between" > consonants instead of "over" them. This will be solved in Firefox 3 for all versions. Meanwhile you may be able to use a version of Firefox with Pango enabled. See http://sinhala.linux.lk/enabling-pango-in-firefox-to-enable-sinhala

(In reply to comment #30) > (In reply to comment #23) > > In Linux, but not in Windows, Firefox displays Arabic short vowels "between" > > consonants instead of "over" them. > > This will be solved in Firefox 3 for all versions. I'll be overjoyed when this bug is fixed, even if only in Gecko 1.9, but I'll believe it when I see it in a Sm trunk nightly. > Meanwhile you may be able to > use a version of Firefox with Pango enabled. See > http://sinhala.linux.lk/enabling-pango-in-firefox-to-enable-sinhala > That page applies only to Fedora and Ubuntu distributions of Firefox. I use Mozilla distributions of both Fx2 (Gecko 1.8+) and SeaMonkey (Gecko 1.9a), as downloaded straight from ftp.mozilla.org, currently the following: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070131 BonEcho/2.0.0.2pre" - Build ID: 2007013104 Configure arguments: --enable-application=browser --enable-update-channel=nightly --enable-update-packaging --disable-debug '--enable-optimize=-Os -freorder-blocks -fno-reorder-functions -gstabs+' --disable-tests --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --enable-svg --enable-canvas --enable-static --disable-shared "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070131 SeaMonkey/1.5a" - Build ID: 2007013101 Configure arguments: --enable-application=suite --disable-tests --enable-extensions=default,tasks --without-system-nspr --without-system-jpeg --without-system-zlib --without-system-png --without-system-mng --disable-debug '--enable-optimize=-O2 -gstabs+' --enable-crypto --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2 --disable-xprint --disable-canvas --disable-svg Both of them exhibit the bug, both with MOZ_DISABLE_PANGO unset and with MOZ_DISABLE_PANGO=0 . Any ideas?

As of today new SeaMonkey builds should be produced with the following config: '--enable-optimize=-O2 -gstabs+' --enable-canvas --enable-svg --enable-pango --enable-default-toolkit=cairo-gtk2

(In reply to comment #32) > As of today new SeaMonkey builds should be produced with the following config: > '--enable-optimize=-O2 -gstabs+' --enable-canvas --enable-svg --enable-pango > --enable-default-toolkit=cairo-gtk2 > New as of today: seamonkey-installer-bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Let's try to unpack the non-installer .tar.bz2: unpacking works, but: /usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory rpm -qa |grep stdc libstdc++-3.3.5-5 libstdc++-devel-3.3.5-5 On Novell-SUSE Linux Professional 9.3 Do you think I should open a new bug?

(In reply to comment #33) Yes, that certainly merits opening a new bug.

(In reply to comment #34) > (In reply to comment #33) > Yes, that certainly merits opening a new bug. > Done: bug 368990

(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #33) > > Yes, that certainly merits opening a new bug. > > > > Done: bug 368990 > Resolved WONTFIX by bsmedberg. "Upgrade to SuSE 10 or stay with the old malfunctioning January version of SeaMonkey."

Right now there are two serious regressions that make Arabic unreadable on trunk builds: bug 369198, which has a patch awaiting review, and bug 368996.

I have finally succeeded to upgrade to openSUSE 10.2. "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a3pre) Gecko/20070210 SeaMonkey/1.5a" (Build ID: 2007021001), a Cairo build, does not exhibit this bug; but it suffers from bug 368996 on Arabic text in some (not all) fonts invoked by CSS and present on the system.

The original bug described has been fixed. All of the bugs reported in the comments, except bug 368996, have also been fixed. Is this a meta bug? Shouldn't it be closed?