Bug 75677 - Font+locale (utf8) problem for gtk+ apps
Summary: Font+locale (utf8) problem for gtk+ apps
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gtk+   
(Show other bugs)
Version: 8.0
Hardware: All Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-10 22:47 UTC by Nicolas Mailhot
Modified: 2007-04-18 16:47 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-14 23:10:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
corefonts spec file for testing (5.08 KB, text/plain)
2002-10-10 22:47 UTC, Nicolas Mailhot
no flags Details
Messup example (32.68 KB, image/png)
2002-11-03 22:41 UTC, Nicolas Mailhot
no flags Details

Description Nicolas Mailhot 2002-10-10 22:47:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020809

Description of problem:
Since the default font for gtk+ apps is awfull on my display, and all controls
to set the font for gtk+ themes seem to have vanished, I had this cunning plan
of changing the aliases of fixed and variable to fix all legacy apps at once.

So I got corefonts, and created a fonts.alias with :

fixed    "-monotype-Courier New-medium-r-normal-*-*-120-*-*-*-*-iso8859-15"
variable -microsoft-Verdana-medium-r-normal-*-*-120-*-*-*-*-iso8859-15

And bingo, a lot of legacy apps look decent now.
Unfortunately this seems to nuke localisation, all non-ascii letters render
strange now in the widgets, and selecting iso10646-1 instead of iso8859-15 or
iso8859-1 nuke *all* letters (displayed as empty boxes).

Seems gtk+ has a problem with the default RH utf8 french locale :(

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install the corefonts (from sf, for example)
2. comment-out fixed and variable aliases in misc/fonts.alias
3. create a fonts.alias like the one listed before in corefonts dir
4. look at galeon/evolution after setting locale to fr (or fr.utf8)

Actual Results:  strange non-ascii letters mangling in the widgets

Expected Results:  ad-hoc display

Additional info:

I'll attach a corefont spec file a bit more integrated with RH 8.0 than the sf
one so tests are easier

Comment 1 Nicolas Mailhot 2002-10-10 22:47:56 UTC
Created attachment 79867 [details]
corefonts spec file for testing

Comment 2 Owen Taylor 2002-10-31 22:31:48 UTC
- What applications are you having problems with fonts in?
  GTK+-1.2 apps like evolution use an entirely different font
  systems than the GTK+-2.0 apps that form the core of the
  GNOME desktop.

- I would not expect changing the 'fixed' or 'variable' aliases
  to have any effect on the fonts used by GTK+-1.2 apps.

- Is your home directory inherented from an older Red Hat system?
  Is there any font specified in ~/.gtkrc or ~/gtkrc-mine?

- Are you logging into GNOME or running the GTK+ apps from a different

Comment 3 Nicolas Mailhot 2002-11-03 12:06:38 UTC
So far, evolution and galeon (before I switched to galeon 1.3)
Might have problems in mozilla too, except I do not run a localized version.

System is a clean RH 8.0 install, apt-rawhidized, I didn't preserve home dirs, 
but saved them on a CD and let the system re-create new dotfiles.

Desktop is gnome2.

Seems the default gtk-1.2 rcfile uses fixed as mainfont, since that is the font 
I see. However Why it mucks a perfectly good truetype I don't know (or maybe 
the fresh po files expect a strange charset)

Comment 4 Emmanuel Kowalski 2002-11-03 15:28:58 UTC
I had a similar problem which turned out to be due to the fact that
the ISO885915 fonts were not installed (clean RH 8.0 install also),
probably from oversight on my part. Also I did change the i18n config
file  /etc/sysconfig/i18n to set LANG="en_US.iso885915" instead of utf8
(because less wouldn't display my latin1 files correctly otherwise), and
I don't know if the two issues are mixed... Anyway checking if
  $ rpm -qa | grep fonts
displays the ISO885915 package might be useful.

    Emmanuel Kowalski

Comment 5 Nicolas Mailhot 2002-11-03 22:40:08 UTC
Well, the point *is* to use nice scalar fonts instead of the ones shipped with RH.

And I *know* these truetype provide all the required glyphs, that's the nice
thing about using corefonts, they provide all european encodings.

[nim@rousalka nim]$ locale

Wich is the default french locale on RH 8.0

I'll attach a screeshot to show the result (which made me realise the Gimp is
also affected, no big surprise here)

Comment 6 Nicolas Mailhot 2002-11-03 22:41:15 UTC
Created attachment 83369 [details]
Messup example

Comment 7 Nicolas Mailhot 2002-11-03 22:57:18 UTC
To make the problem clear, I'm glad I found a way to change the font used by
gtk1 apps, since all gui-setups have disappeared for these libs. I'd prefer them
to use + variable ;, but I'll go with + fixed ;.

What I'm not happy at all with is the inability of gtk1 to extract non-ascii
glyphs out of the selected font without messing up, since I know this font
contains the required glyphs and it has been correctly indexed by ttmkfontdir
and friends (I you doubt me look at the attached spec file, I spend enough time
studying RH's font spec-files to be sure I didn't forget anything).

gtk2 is working flawlessly with the same fonts (not surprising since fontconfig
was developped and tested on corefonts). Unfortunately as Alan Cox wrote
recently on linux-kernel gtk1 is here to stay for a long time, so it better work
 on non ASCII locales.

BTW I think localized initscript startup messages are also borked on my system,
so I suspect some hack in the semi-unicode fonts that RH ships which breaks on
all other common fonts (that's just a suspission, as the first utf8 release I
expect it to breaks at the seams)

Comment 8 Owen Taylor 2002-11-03 23:23:18 UTC
Hmm. Well, considering that GTK+ is using 'fixed' on your system,
the problem with the literal UTF-8 appearing makes some sense.

Basically, GTK+ first is going to try to load the font specified
in /etc/gtk/gtkrc.utf8 -


If that fails then GTK+ falls back to first:


then to 


But only only the font in gtkrc.utf8 is loaded appropriately
for a UTF-8 locale.

So, at this point, my expectation is that:

 xlsfonts -fn '-*-helvetica-medium-r-normal--*-120-*-*-p-*-*-*'

produces no matches on your system. Is XFree86-75dpi-fonts package
installed on your system? 

BTW - the appropriate way to set the gtk+1 font on your system would
be to create a  ~/.gtkrc.mine file with the contents:

 style "user-font" {
       fontset = "-microsoft-Verdana-medium-r-normal-*-*-120-*-*-*-*-*-*"
 widget_class "* style "user-font"

Comment 9 Nicolas Mailhot 2002-11-03 23:47:59 UTC
XFree86-75dpi-fonts is not installed - on 100+ dpi sceens it produces little
more than unreadable fly dungs. That's one of the main reasons I use truetype
fonts everywhere (apart from fsthetical considerations and broad encoding
support) : they don't try to ram a specific dpi in your throat (if I had one
thing to say about the new gtk2 font rendering dialog it's that it do not read X
dpi info but forces a 96 or whatever dpi on the user. All nice but it breaks
horribly in nfs setups where all stations do not have the same dpi value ; at
least gimp can read X hints).

Your trick works (modulo a missing "). However I'd really prefer a working fixed
alias (works for all apps, all users). Somehow putting stars in the encoding do
not work for fixed, and why should iso8859-15 work in the gtkrc but not the
alias ? (I know deep X legacy borked font handling, I can't wait for a fully
fontconfigged setup)

RH should really restore some form of gui control for gtk1 font handling ; the
plain fact is the default font suck for lots of users, and not everyone is a
gtkrc master.

Anyway, thanks for this answer

Comment 10 Nicolas Mailhot 2003-01-14 09:36:54 UTC
I'll leave it up to you whether this bug should be closed or not. Deep gtkrc
vodoo is really user-unfriendly

Comment 11 Owen Taylor 2003-01-14 23:10:30 UTC
There is something about it in the release notes now, so it's at least
documented prominently.

Adding a GUI won't be done for a couple of reasons:

  - By the time it got into a release, it would be even less need
    for it than now.
  - We no longer have widgets in our GUI toolkits for selecting
    XLFDs graphically.
  - A XLFD selection option in the GUI would still be incomprehensible
    to non-hackers.
  - There are all sorts of traps when selecting XLFD's - at least by
    using something standard, users should generally get something that
    _works_ for their language, even if it is ugly or the wrong size.
  - It would be very hard to find a place inthe GUI to launch such
    a config tool, a:

      [ Configure fonts for apps where other font configuration doesn't work ]

It's basically a lot of work for only moderate gain.

Comment 12 Nicolas Mailhot 2003-01-15 08:43:30 UTC
I suspected something like this, that's why I told you to close the bug if you
wanted to. The workaround is good enough for me. Thank you again.

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