From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020712
Description of problem:
In gnumeric on the non standard gtk widgets (the table itself) the fonts appear
spaced out. I t l o o k s k i n d a l i k e t h i s .
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. launch gnumeric
2. click in a cell
3. type a few characters
Actual Results: s p a c e d o u t l e t t e r s
Expected Results: normal spacing
Frustrated testers might want to know that gnumeric-1.1.6 and abiword cvs (with
--enable-xft) do not exhibit this bug
Gaim and Sylpheed also exhibit this on my system. I have installed the 75 and
100 dpi fonts that were left out of the installer.
Sylpheed is pretty much unusuable (text runs off the edges), and Gaim does not
function very well with the miskerned fonts. In gaim you cannot see the names
of who is talking, most likely font related.
In gaim after turning on ignore incoming faces, the only issue i had was with
italicised text which doens't seem to display
Upon computer reboot due to power failure, I realized that I hadn't restarted x
font server, only X. Gaim and Sylpheed now work properly. Gaim still has the
aforementioned problem with italicised text.
I see this behaviour (by using Reflection X from a Windows to a Linux box) too
in the non GTK2 applications (gftp, gnumeric, .. ) in Limbo beta 2.
(see attached screenshot)
Created attachment 69004 [details]
X session via Reflection showing gftp
i just tested the newer rawhide version -- gnumeric-1.0.9-2 -- and while
the text looks better, it is still spaced out too much.
weirdly, in my example, the bold text looks fine; it's the regular
non-bold that is spaced too much.
so, it's better but still not there.
What this is a symptom of is that given the font specification that
gftp is using, gftp can't find any of the encodings for your locale
(probably iso10646-1 and iso8859-1, assuming en_US.UTF-8).
It then assumes that the font that it does find is in the first
encoding of the locale iso10646-1, and draws a byte string like:
'a' \x00 'b' '\x00' ...
But since your font isn't actually a double byte font (it's not
a Unicode font, which is what a iso10646-1 font is), the \x00
characters bytes end up being rendered as spaces.
To find out why this is happening, we need to find out what font
gtk-1.2 is trying to use... Could you a:
*) Test out if this happens with a newly created account
*) Attach the contents of your ~/.gtkrc file.
I believe that with the GNOME in the second public beta, this
probably won't actually appears, since GNOME redirects GTK+
away from your ~/.gtkrc to ~/.gtkrc-1.2-gnome2, but it might
appear if you logged in in failsafe mode.
Please confirm this is still happening in (Null).
I'm still seeing this problem in a XDMCP connection to a Red Hat Linux
7.3.94 'null') machine.
I'll post a screenshot as an attachment.
Created attachment 72364 [details]
gFTP session via XDMCP on Red Hat Linux 7.3.94 ('null')
Created attachment 72384 [details]
Font spacing in Gnumeric on Red Hat Linux 7.3.94 ('null')
Created attachment 72404 [details]
Screenshot of contents of ~/.gtkrc file
Can you attach the output of :
xlsfonts -fn '-*-helvetica-medium-r-normal--*-120-*-*-p-*-*-*'
Connected to that display?
Created attachment 72864 [details]
Output of xlsfonts
In the supplied OpenOffice package in Red Hat Linux release 8.0.92 (Phoebe) this
problem can still be reproduced. Part of this package is the program "oosetup",
which displays some really wacked fonts. See attached screenshot.
Created attachment 88954 [details]
Screenshot show GTK1(?) fonts problem in Phoebe
I'm pretty sure the OpenOffice installer isn't using GTK+ --- certainly
the rest of OpenOffice doens't'. So, you probably should file a separate
bug about that.
Definitely sounds like a problem related to Unicode locales. For all
the applications I see listed here-- gnumeric, gaim, gftp, OpenOffice,
abiword, sylpheed-- the problem is resolved. Recommend closing.
Ok, clearly right now on my stock FC2 gnumeric/gftp/OOo/etc work fine,
I'll go out on a limb here and say it works now. If there is a
contemporary example of this reappearing then re-open this and we'll
go digging again.