Closed Bug 182650 Opened 22 years ago Closed 22 years ago

[Xft][Xrender bug?]text with certain characters not displayed

Categories

(Core Graveyard :: GFX: Gtk, defect, P3)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 190278

People

(Reporter: bukovjan, Assigned: blizzard)

References

(
URL
)

Details

Attachments

(1 file)

Screenshot for mozilla 1.2 GTK2/XFT
(deleted), image/png
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.2) Gecko/20021126 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.2) Gecko/20021126 This site does not look quite as it should, and as it used to in Mozilla 1.1 (non-xft) or currently does in Konqueror. Looks like serious font rendering problem, related to Unicode and xft (switching page encoding to Central European ISO-8859-2 helps). Reproducible: Always Steps to Reproduce: 1. Go to the URL. 2. 3. Actual Results: Text is not rendered for most articles. Expected Results: Render it! Maybe it is related to bug 179181. The build I use is for Mandrake Cooker, I think it is built using gtk2 and xft.
Blocks: xft_tracking
Could you give the URL of one of the pages where the text doesn't render (rather than the URL for the site)? Or is the homepage an example of the problem? (I followed one of the links from the URL you gave, and that page looked fine to me once switched to the correct encoding.)
Confirming problem on main page.. Screenshot following.. Page is detected as "UTF-8" but only render correctly when switching to ISO-8859-2.. Mandrake Cooker build for Mozilla 1.2 are GTK+2 AND XFT build..
Attached image Screenshot for mozilla 1.2 GTK2/XFT (deleted) —
The problem is the home page (and any other page on this site). After you switch to the correct encoding, it renders OK. i looks much like the bug 179181, except there is no text, not just the accented characters. On a related note, there is another bug - leave the page in the default (i.e. Unicode) encoding, now View source (same bug in here), and switch encoding (to Central European ISO-8859-2) in View source screen - no source at all!
I think this is because of non-standard 8bit chars that are in the page, not in the &char form. I can see that as soon as there is such an accented character, entire line is not rendered. Try this: begin selecting words on a line in some article. As long as there is no accented char in the selection, the selection is displayed. As soon as an accented (8bit) character becomes selected, the selection will cease displaying.
Oh, I interpreted "switching page encoding to Central European ISO-8859-2 helps" to mean that it helps but it doesn't fix all the problems. But I guess you meant that the whole problem is the character encoding detection, right?
Well, first, the problem is empty space displayed, in any case (this should never happen). Second, there is a serious bug in View source and encoding switching there. Third, seems like encoding detection problem; looking at the page, though, it should display as ISO-8859-2, see HTML header: <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"> <title>underground - 29. 11. 2002</title> <link rel="shortcut icon" href="http://im2.underground.cz/favicon.ico" type="image/x-icon"> </head> There seems to be no HTTP header (at least not if I try a telnet session on port 80).
*** Bug 187085 has been marked as a duplicate of this 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. (It appears that Bug#187377 is a duplicate of this bug report.) Cheers, Anthony
I don't think this is related to the XRender bug, since it is already fixed in cooker (it was a bug in XFree 4.2.0/fcpackage 2.0 Xrender and we now uses XFree 4.3 snapshot which already fixed this) and this bug was causing rendering to failed in BOTH iso8859-2 and utf-8. Be sure to change page encoding from iso8859-2 to utf-8 otherwise you won't see the problem.
Priority: -- → P3
*** Bug 187377 has been marked as a duplicate of this bug. ***
*** Bug 187335 has been marked as a duplicate of this bug. ***
Summary: text rendering missing in xft enabled build for this site → [Xft][Xrender bug?]text with certain characters not displayed
*** Bug 196684 has been marked as a duplicate of this bug. ***
->correct component, too.
Assignee: font → blizzard
Status: UNCONFIRMED → NEW
Component: Layout: Fonts and Text → GFX: Gtk
Ever confirmed: true
*** Bug 195975 has been marked as a duplicate of this bug. ***
*** Bug 197727 has been marked as a duplicate of this bug. ***
Following the advice in comment #9, I updated my (debian) box to XFree86 4.3 (check http://www.apt-get.org/ for places to get nice precompiled debs from), and this problem, which had been annoying me for quite some time (see comments 8 & 9 in bug #187377), now works just fine- ASCII and Japanese characters now display properly, and selecting the text doesn't make it disappear/reappear & jump all over the place (see first two attachments in bug #187377). So, this bug (at least as it's described in #187377) can probably be closed as INVALID..
Marking INVALID.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Not so fast. Try comment #10. I am using Mandrake 9.1/Cooker, and this bug is still present with XFree86 4.3.0 and Mozilla 1.3 final. If you go to http://www.underground.cz and switch the encoding to UTF-8, you will see virtually nothing. Of course, I bump into this bug quite often here and there, including reading emails (!) and this missing lines of text are quite annoying. I vote for reopening this bug, unless this is really an XFree86 issue.
> If you go to http://www.underground.cz and switch the encoding to UTF-8, you > will see virtually nothing. If you switch the encoding to something that it isn't, you get what you asked for -- garbled text.
Hmm, yes, but I am not talking about garbled text. I am talking about *missing* text till the end of the line after the first "invalid" character is reached. Consider the following, common scenario: 1. I have ISO-8859-2 as my default charset. 2. Most US pages do not have any charset specified, so ISO-8859-2 is picked, instead of ISO-8859-1. 3. Sometimes there is a character ISO-8859-2 cannot handle, like typographical symbols, certain types of quotes, signs for trademarks, etc. 4. If such a character occurs, the rest of a line is not displayed, not just the character in question. With Windows or GTK+ 1.x version of Mozilla, for example, a question mark or garbled character is displayed, but the rest of the text line is displayed as well, so I can actually read the sentence. So while the above descibed problem is not typical situation, it shows the problem that I bump here and there on other pages quite well and clearly.
Re-open to dup.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
dup *** This bug has been marked as a duplicate of 190278 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: