Created attachment 79867 [details]
corefonts spec file for testing

- 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
  desktop?

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)

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

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
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

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)

Created attachment 83369 [details]
Messup example

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)

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 -

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

If that fails then GTK+ falls back to first:

 font=-adobe-helvetica-medium-r-normal--*-120-*-*-*-*-iso8859-1

then to 

 font=fixed

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"

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

I'll leave it up to you whether this bug should be closed or not. Deep gtkrc
vodoo is really user-unfriendly

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 ]
   
    Button?

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

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.