[BiDi] composing characters are separated from their base.

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
18 years ago
9 years ago

People

(Reporter: arthur.barrett, Assigned: smontagu)

Tracking

({intl})

Trunk
All
Linux
Points:
---
Bug Flags:
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

18 years ago
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.

Comment 1

18 years ago
Reassign to ftang.
Assignee: nhotta → ftang

Comment 2

18 years ago
katakai- it looks like GTK hebrew rendering issue. Can you take a look at it?
Assignee: ftang → katakai

Comment 3

18 years ago
Prabhat, can you take this?
(Reporter)

Comment 4

18 years ago
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.

Comment 5

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

Comment 6

18 years ago
Assign to prabhat.hegde@eng.sun.com.
Assignee: katakai → prabhat.hegde

Comment 7

18 years ago
Changing QA contact to giladehven@hotmail.com.

Changing component to "Bidi..." and adding intl keyword.

Gilad, can you confirm (reproduce) this problem?  Thanks.
Component: Internationalization → BiDi Hebrew & Arabic
Keywords: intl
QA Contact: andreasb → giladehven

Comment 8

18 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 9

18 years ago
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/
----------------------------------------------------------------
(Reporter)

Comment 10

18 years ago
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.


Comment 11

18 years ago
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. 
QA Contact: giladehven → zach

Updated

18 years ago
Blocks: 115713
(Assignee)

Comment 13

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

Comment 14

18 years ago
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
Assignee: prabhat.hegde → ftang
reassign to smontagu as per ftang's comment
Assignee: ftang → smontagu
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED

Comment 18

17 years ago
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

Comment 20

15 years ago
updated per comment 19
OS: Solaris → Linux
Hardware: Sun → All

Comment 21

14 years ago
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.

Comment 22

14 years ago
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.
(Assignee)

Comment 30

12 years ago
(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?
(Assignee)

Comment 34

12 years ago
(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."
(Assignee)

Comment 37

12 years ago
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
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?
(Assignee)

Updated

11 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9+
Whiteboard: [wanted-1.9]

Updated

11 years ago
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.