Closed Bug 405393 Opened 14 years ago Closed 14 years ago

ZWNJ and ZWJ unicode characters are failing to render correctly.

Categories

(Core :: Layout, defect, P2)

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.9beta3

People

(Reporter: panemade, Assigned: karlt)

Details

(Keywords: intl, regression)

Attachments

(5 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

Using Firefox 3.0b1, I tried to open some Indic websites but I saw that combinations formed using ZWNJ and ZWJ are failing now which is not the case in Firefox 2.0.0.9


Reproducible: Always

Steps to Reproduce:
1.install firefox 3.0b1 binary tarball.
2. start firefox
3. open ml.wikipedia.org or te.wikipedia.org or kn.wikipedia.org or si.wikipedia.org
4. check for Unicode Glyph boxes(no actual characters)
Actual Results:  
Unicode Characters are being displayed as Glyphs boxes(no actual characters)

Expected Results:  
It should render correctly and display characters and not Glyphs boxes.

This looks regression. This problem is not present in firefox 2.0.0.9
-> NEW

roc:
Would you check this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl, regression
Version: unspecified → Trunk
I'll check it on someone else's Linux box tomorrow.
reproducible here: likely related to the assertion below:

(Gecko:28877): Pango-WARNING **: Error loading GDEF table 85

(Gecko:28877): Pango-WARNING **: Error loading GSUB table 85

(Gecko:28877): Pango-WARNING **: Error loading GPOS table 85
###!!! ASSERTION: Ended word in the middle of a cluster...: 'end == aSource->GetLength() || aSource->IsClusterStart(end)', file /home/karl/moz/mozilla/gfx/thebes/src/gfxFont.cpp, line 1866
###!!! ASSERTION: Ended word in the middle of a cluster...: 'end == aSource->GetLength() || aSource->IsClusterStart(end)', file /home/karl/moz/mozilla/gfx/thebes/src/gfxFont.cpp, line 1866
(last assertion repeats a couple of dozen times.)
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Attached file reduced testcase
Here's a reduced testcase.  
  - FF2 renders this as a character.
  - Trunk renders it as three unicode glyph boxes.

I don't see the assertions or pango warnings mentioned in comment 3 when loading this testcase.
Looks like this is both a Mac + Linux issue, both on the testcase and on ml.wikipedia.org.

Mac Trunk:     glyph boxes
Linux Trunk:   glyph boxes
Windows Trunk: no glyph boxes
I left some comments at
https://bugzilla.mozilla.org/show_bug.cgi?id=202352

It works correctly in Windows. And on Linux ZWJ is rendered correctly, the boxes are shown only when a ZWNJ is present.
Praveen,
  This is bug filed against Firefox 3 Beta 1. Are you sure ZWJ is working fine on Firefox 3 Beta 1. I just checked again and I saw many Glyph Boxes of 200D on ml.wikipedia.org website.
Attached image Malayalam Wikipedia in Firefox 3.0b1 (obsolete) —
This screenshot is captured from a machine running Fedora 8 with rachana-g02 fonts
This is the actual screenshot from Firefox 3.0b1. It's captured from a machine running Fedora 8 with rachana-g02 fonts.
Attachment #292935 - Attachment is obsolete: true
(In reply to comment #10)
> Created an attachment (id=292939) [details]
> Wikipedia in Firefox 3.0b1
> 
> This is the actual screenshot from Firefox 3.0b1. It's captured from a machine
> running Fedora 8 with rachana-g02 fonts.
> 

strange to see empty boxes only instead of unicode boxes.
Ok, I also saw empty boxes provided I should zoom out text written in webpage to 2nd level. Normal view of web page showed me unicode glyph boxes on left side but empty boxes on right side.
Parag,

The extra boxes you see in wikipedia for ZWJ is actually ZWNJ only because the popular input scheme used by the majority of wikipedians is buggy and puts ZWNJ in places where it is not required or should not used. See http://santhoshtr.livejournal.com/6819.html for more details of this bug. So currently only ZWNJ rendering is buggy. I tested this against the Dec 11 daily version.
pango_is_zero_width() was only checking the first character in the cluster.
(And we don't know which characters belong to which glyphs.)
PANGO_GLYPH_EMPTY seems to be what we want anyway:

http://developer.gimp.org/api/2.0/pango/pango-Glyph-Storage.html#PANGO-GLYPH-EMPTY:CAPS
Attachment #293066 - Flags: review?(masayuki)
Assignee: nobody → mozbugz
Comment on attachment 293066 [details] [diff] [review]
use PANGO_GLYPH_EMPTY

And I'll remove the
#include <pango/pango-utils.h>
Comment on attachment 293066 [details] [diff] [review]
use PANGO_GLYPH_EMPTY

roc is better reviewer.
Attachment #293066 - Flags: review?(masayuki) → review?(roc)
(In reply to comment #14)
> Created an attachment (id=293066) [details]
> use PANGO_GLYPH_EMPTY
> 
> pango_is_zero_width() was only checking the first character in the cluster.
> (And we don't know which characters belong to which glyphs.)
> PANGO_GLYPH_EMPTY seems to be what we want anyway:
> 
> http://developer.gimp.org/api/2.0/pango/pango-Glyph-Storage.html#PANGO-GLYPH-EMPTY:CAPS
> 

Cool. I applied this patch to FF3 Beta1 tarball and rebuilt binary and found this problem is solved now.

I have patched the trunk and built ff3 and found this issue solved. Please apply this patch to the trunk. A screnshot after patching attached.
zwnj rendering correctly after applying the patch
Comment on attachment 293066 [details] [diff] [review]
use PANGO_GLYPH_EMPTY

Checked in this and removed the pango-utils.h include.
Filed Bug 408897 for the same issue on Mac.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11
Flags: in-testsuite?
Just want to know is this applied to trunk? I thought this will be available in FF3 Beta 2 anyway will wait for FF3 Beta 3 release to include this fix.
(In reply to comment #22)
On trunk in gfx/thebes/src/gfxPangoFonts.cpp revision 1.120.
That was after beta 2 but will be in beta 3.
Karl,
  Thanks for your patch. I have tested nightly builds and issue reported in this bug is now fixed. But I got another issue of unable to print indic webpages see bug 409828.

Thanks.
You need to log in before you can comment on or make changes to this bug.