Characters disappear with xft if fallback triggered twice on the same line

RESOLVED DUPLICATE of bug 182650

Status

()

Core
Layout: Text
RESOLVED DUPLICATE of bug 182650
15 years ago
15 years ago

People

(Reporter: Chung-chieh Shan, Assigned: blizzard)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; zh-TW; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; zh-TW; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9

At http://www.eecs.harvard.edu/~ccshan/mozilla/xft-utf8.html is a UTF-8 page
with four characters: (1) a Chinese/Japanese character, (2) the letter "x", (3)
the same Chinese/Japanese character, and (4) another "x".  When rendering this
page with xft, Mozilla correctly uses one font for the Han characters and
another for the "x"s.  However, only (1), (2), and (4) is rendered; (3)
disappears.  You can get the missing character (3) to appear briefly by
selecting the text.

Reproducible: Always

Steps to Reproduce:
Open the URL http://www.eecs.harvard.edu/~ccshan/mozilla/xft-utf8.html
Actual Results:  
Three characters are shown: a Chinese/Japanese character, followed by "xx".

Expected Results:  
Four characters should be shown: a Chinese/Japanese character, followed by "x",
then the same Chinese/Japanese character, followed by another "x".  This
expected result is demonstrated by the Big5-encoded page at
http://www.eecs.harvard.edu/~ccshan/mozilla/xft-big5.html

This bug seems to be specific to xft.

This bug also appears on UI elements (i.e., with UI text that mixes Chinese
characters and Roman letters).

This bug makes the xft build unusable for many mixed-language and UTF-8 Web
sites.  For example, visit http://home.att.net/~jameskass/scriptlinks.htm and
scroll down to "IPA", or visit http://meta.elixus.org/ and search for the
English name of the current or previous month.  (You might need to select some
text to see what is missing in the xft rendering.)
->blizzard.  This seems similar to bug 187335.  Perhaps the same thing, but more
clearly described?

Was this also a GTK2 build?
Assignee: font → blizzard
Blocks: 172768
Er, never mind about the similarity.
I don't see this problem in my Xft build.  Perhaps this is a problem with one of
the fonts you have installed?  (One that claims to have glyphs that it really
doesn't have?)  It would seem odd for the font that we get the "x" from to claim
to have Chinese characters, though.
(Reporter)

Comment 4

15 years ago
Hello David,

Since the only libgtk mentioned by "ldd /usr/lib/mozilla/mozilla-bin" is
"libgtk-1.2.so.0", I guess it's not a GTK2 build.

As far as I can tell by comparing onscreen display, the Chinese/Japanese
character is being shown in MS Gothic, and the "x" in Times New Roman.  I
removed lines from /etc/fonts/fonts.conf so that neither of these fonts are
known to Mozilla anymore, but the problem persists.

When you get back to campus, I'll gladly demonstrate the problem on my laptop. (:

Comment 5

15 years ago
I believe I'm seeing the same thing.  I noticed the effect on the first URL in
the description before I found this bug report.  I don't know that I can be much
help in tracking it, but I thought I'd let you know you're not the only one
seeing this wonkiness.  <a href="http://litui.net/unicode/thai.utf-8">This
file</a>, a UTF-8 text file seems to be showing some of that oddness.  I'm
seeing the same thing on <a
href="http://www.livejournal.com/talkpost.bml?journal=litui&itemid=30739">text
in a recent journal entry</a> as well.

Comment 6

15 years ago
I believe I'm seeing the same thing.  I noticed the effect on the first URL in
the description before I found this bug report.  I don't know that I can be much
help in tracking it, but I thought I'd let you know you're not the only one
seeing this wonkiness.  http://litui.net/unicode/thai.utf-8 , a UTF-8 text file
seems to be showing some of that oddness.  I'm seeing the same thing on
http://www.livejournal.com/talkpost.bml?journal=litui&itemid=30739 as well.
(Reporter)

Comment 7

15 years ago
I confirm the same problem at the two URLs posted immediately above.

Comment 8

15 years ago
Created attachment 112345 [details]
invisible words after Japanese

I can also confirm that the links given above exhibit the same weird behavior. 
It seems to happen only with UTF-8, and whenever a regular ASCII character
appears after a 2-byte character (i.e. Japanese).

I'm using the following deb's: mozilla-browser, mozilla-psm, & mozilla-xft
(1.2.1-9 of all).

Comment 9

15 years ago
Created attachment 112346 [details]
selecting the text makes it reappear

For those who can't reproduce, here's what happens when you select something
near the invisible text- it magically reappears.

There are also problems with spacing, i.e. if you have something like a list of
Japanese words separated by a normal ASCII comma and space, the commas & spaces
disappear & the Japanese words get all bunched together..  If you'd like
another screen shot, let me know. :)

Comment 10

15 years ago
Hi,
I think I have encountered the same problem with Japanese characters.
After some experiments, I came to think that what matters is not encoding, but
the fonts.
The problem looks complicated because Mozilla has different default fonts for
different encodings.
Please specify the fonts in your HTML document, and I guess the problem will
occur even in
non-UTF-8 pages.

For example, on my environment,
http://www.eecs.harvard.edu/~ccshan/mozilla/xft-utf8.html did
not cause the problem.
I think this is because the font selected on my environment (I do not know
which) has both
Japanese characters and English characters.
On the other hand,
http://www.livejournal.com/talkpost.bml?journal=litui&itemid=30739 caused
the problem.  This is _not_ because the pages are written in UTF-8, but because
Verdana font,
the font selected first on my environment, has only English characters.

In case anyone is interested in the experiment I performed:
- Explanation: http://www-imai.is.s.u-tokyo.ac.jp/~tsuyoshi/mozilla-fonts/
- Experiment page:
http://www-imai.is.s.u-tokyo.ac.jp/~tsuyoshi/mozilla-fonts/xfttest.html
- Resulting image:
http://www-imai.is.s.u-tokyo.ac.jp/~tsuyoshi/mozilla-fonts/xfttest.png
However, be warned all these are written in Japenese!

Comment 11

15 years ago
I confirm the bug on my
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030213

Mozilla is built with Xft.

I can add that I get very similar font rendering weirdos on some cyrillic pages
with windows-1251 & koi8-r encodings (didn't check UTF-8).

Most of the time rendering is fine, but on some pages I see only first word in
each line of text. I can make the rest of the line to reappear shortly by
selecting it.

I'll try to post a screenshot.

Comment 12

15 years ago
Created attachment 114422 [details]
Invisible cyrillic chars (the whole page of them)

Punctuation marks are visible and all the words in English are too!

Comment 13

15 years ago
Created attachment 114423 [details]
What happens when I select the invisible text

The same page as on my previous screenshot but I selected some text with my
mouse.
Look, some chars inside the selected area became visible and also some chars
after the selected area on the same line became visible, but they're all messed
up together, no blanks between words, no punctuation.

Comment 14

15 years ago
Looks like 182650 is the same bug.

Comment 15

15 years ago
This is not a Mozilla bug, but rather, a XFree86/libXrender one, which has been
fixed in XFree86 CVS (post 4.2.1) some months ago.  Owen Taylor and Mike Harris
included this fix in Red Hat 8.0:

* Sun Sep 01 2002 Mike A. Harris <mharris@redhat.com> 4.2.0-70
- Updated custom startup log patch to fix a few glitches
- Added -fPIC to x86_64 compiler flags until better solution is made in future
- Added XFree86-4.2.0-libXrender-bugfix.patch to fix showstopper (#73243)

See  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73243

AFAIK, neither Debian (the latest unstable/sid) nor FreeBSD has picked up this
patch yet.  I added the patch to my Debian (sid) machine (built locally as
XFree86-4.2.1-5.1), and it works for me.  :-)  Please try it out and see if it
fixes your problem too.

Cheers,

Anthony

Comment 16

15 years ago
I can verify that the xrender fix Anthony points to works.  I just recompiled
xfree86 4.2.1 last night in debian including the supplied patch and after
installing the newly compiled xlibs package, this issue is gone.  I have also
verified with a friend that it is gone in new versions.  Thanks for the link,
Anthony.

*** This bug has been marked as a duplicate of 182650 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.