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?

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.

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. (:

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.

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.

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

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).

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. :)

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!

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.

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

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.

Looks like 182650 is the same bug.

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

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 ***