Bug 77045 - gtk 1.4 apps in gnome2 environment garble text on remote display
Summary: gtk 1.4 apps in gnome2 environment garble text on remote display
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
 
Reported: 2002-10-31 10:46 UTC by Jamie Zawinski
Modified: 2007-04-18 16:48 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Jamie Zawinski 2002-10-31 10:46:01 UTC
I tried to remote display grip from a fresh install of Red Hat 8.0 to a
box running Red Hat 7.3.  All text in all labels and text fields is
garbled: there is a square "box" character inserted between every real
character in labels and text fields.  So if it should say

    foobar

instead it looks like

    f[]o[]o[]b[]a[]r[]

Someone suggested setenv GDK_USE_XFT 0; that did not help.

This happens in both 24 bit truecolor and 8 bit pseudocolor mode.

The machine on which the apps are running is a fresh install of Red Hat
8.0.  The machine on which the apps are *displaying* is a Red Hat
7.3+Ximian box, with XFree86-4.2.0-72.

% rpm -q grip
grip-3.0.1-4

% ldd `which grip`
	libgnomeui.so.32 => /usr/lib/libgnomeui.so.32 (0x4001e000)
	libart_lgpl.so.2 => /usr/lib/libart_lgpl.so.2 (0x40106000)
	libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x40115000)
	libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4013b000)
	libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40144000)
	libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4015b000)
	libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x402b5000)
	libm.so.6 => /lib/i686/libm.so.6 (0x402ef000)
	libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40311000)
	libdl.so.2 => /lib/libdl.so.2 (0x40314000)
	libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40317000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4031f000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4032d000)
	libgnome.so.32 => /usr/lib/libgnome.so.32 (0x4040c000)
	libgnomesupport.so.0 => /usr/lib/libgnomesupport.so.0 (0x40425000)
	libesd.so.0 => /usr/lib/libesd.so.0 (0x4042a000)
	libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40432000)
	libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40456000)
	libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4047c000)
	libghttp.so.1 => /usr/lib/libghttp.so.1 (0x404ad000)
	libcdda_interface.so.0 => /usr/lib/libcdda_interface.so.0 (0x404b5000)
	libcdda_paranoia.so.0 => /usr/lib/libcdda_paranoia.so.0 (0x404c6000)
	libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x404ce000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40580000)
	libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
	libdb.so.2 => /usr/lib/libdb.so.2 (0x40589000)
	libz.so.1 => /usr/lib/libz.so.1 (0x40597000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$LANG on the RH 8 box is "en_US.UTF-8".

grep -i font ~/.gtkrc*

     no match

grep -i font /etc/gtk/gtkrc.utf8

     fontset = "-*-helvetica-medium-r-normal--*-120-*-*-p-*-*-*"

running xlsfonts -fn '-*-helvetica-medium-r-normal--*-120-*-*-p-*-*-*'
on the 8.0 box with $DISPLAY pointing at the 7.3 box:

    -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1
    -adobe-helvetica-medium-r-normal--17-120-100-100-p-88-iso8859-1
    -urw-helvetica-medium-r-normal--17-120-100-100-p-0-iso8859-1

Setting $LANG to C makes grip behave correctly.

Comment 1 Owen Taylor 2002-10-31 21:39:05 UTC
Does it happen for all gtk1 apps or just grip?


Comment 2 Jamie Zawinski 2002-10-31 21:50:37 UTC
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)


Comment 3 JLapham 2002-11-04 17:43:11 UTC
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...


Comment 4 Owen Taylor 2003-01-15 04:27:11 UTC
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


Comment 7 Mike A. Harris 2003-02-07 13:23:09 UTC
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.

Comment 8 Owen Taylor 2003-02-11 03:53:40 UTC
I don't fully understand your comment. Yes, it's a data file change,
not a source code change; why is that relevant?


Comment 9 Mike A. Harris 2003-07-10 14:44:56 UTC
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.


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