Bug 77045
Summary: | gtk 1.4 apps in gnome2 environment garble text on remote display | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Jamie Zawinski <jwz> |
Component: | XFree86 | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | mitr, otaylor |
Target Milestone: | --- | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-10-08 22:57:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 123268 |
Description
Jamie Zawinski
2002-10-31 10:46:01 UTC
Does it happen for all gtk1 apps or just grip? Also happens for: xchat-1.8.10-8 gftp-2.0.13-5 glade-0.6.4-7 gqview-1.0.2-2 nmap-frontend-3.00-1 so I'm thinking "all programs using libgtk-1.2.so.0" (gtk+-1.2.10-22) jwz- Just a shot in the dark, but I wonder if this is somehow related to bug 76248 that I reported. Im my case, changing from LANG=en_US.UTF-8 to LANG=en_US fixed the problem. You mention changing LANG to "C" fixed the problem for you, what happens if you try en_US? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76248 -Jon PS: yeah, these two problems are probably unrelated... I'm just hoping to stir up *some* response on these bugs... After setting up a test environment, finding a pure-Xlib test case, spending a bunch of time tracing through Xlib, I suddenly remembered a detailed analysis of this exact problem. Namely: http://www.mail-archive.com/i18n@xfree86.org/msg00825.html By me, in fact. It turns out that this is a Hard Problem. (Because Xlib i18n is screwed up in ways that I can't describe in a family bugzilla report). There is a simple change to the Xlib configuration files that will make this problem go away. Edit /usr/lib/X11/locale/en_US.UTF-8/XLC_LOCALE and move the fs0 entry to the end and renumber fs0 through fs6. However, this ruins the nice property that if you have an iso10646-1 font, and you specify -xlfd-to-my-font-iso10466-1,other-stuff You are guaranteed to get your font and only your font. (iso10646 is functionally equivalent to Unicode.) It also will be noticeably less efficient in some cases. That being said, I'm of the opinion that we should go ahead and make this change, basically because X fonts are a legacy item at this point, so we should favor: - Simplicity and reliability of getting something on the screen As compared to: - Power of configuration - Efficiency The suggestion you're making is with an installed system file and not from the source code. The two differ as I've just had a peek at this. Since you understand the problem much deeper than I do, please make a patch to the X source code and attach it for inclusion, preferably after testing it first to ensure it does what is expected. I don't fully understand your comment. Yes, it's a data file change, not a source code change; why is that relevant? Because patching the source code is easiest if the patch was created against the source code. A lot of the data files included in XFree86 installation are modified versions which were produced through automatic processes during X building, and a patch made against the installed system versions wont apply to the source code version. Rather than try to patch it, I prefer to get patches made from the source code files to start with, which the person submitting the patch has actually tested applying it to XFree86 sources. It's less work on my end to do this way. Alternatively send it upstream, and it can be pulled out of CVS once it is committed. |