Bug 27073 - Messed up font selection
Messed up font selection
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gnome-libs (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
Ben Levenson
:
: 27809 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-11 14:24 EST by Michal Jaegermann
Modified: 2007-04-18 12:31 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-15 16:44:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cyrilic text in supposedly cyrilic font (87.76 KB, image/jpeg)
2001-02-11 14:26 EST, Michal Jaegermann
no flags Details
Latin2 text in claimed latin2 font (14.61 KB, image/jpeg)
2001-02-11 14:27 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2001-02-11 14:24:24 EST
'gnome-terminal' from Fisher has serious troubles with a font selection.
After picking up a font in a browser and hitting "Apply" button results
are totally unpredictable.  Sometimes a font is changed, but not
necessarily on what one wants, sometimes some change is applied to
the _next_ terminal window which will be opened and sometimes nothing
happens save a font name in "Preferences" panel.  I do not see any
rhyme or reason in this behaviour.  And yes, /etc/X11/fs/config was
properly updated to include all fonts in question in 'catalogue'.

Two examples are included.  The first, pseudocyr.jpg, shows a screen
capture from a gnome-terminal window on some cyrilic text in what is
purported to be

-Cronyx-Courier-Medium-R-Normal--14-100-100-100-M-80-KOI8-R

font.  It is clear that this is noting of that kind because displayed
glyphs do not even exists in ANY font from a "Cronyx" family.  Besides
when xterm with the font above is used then the sample displays correctly.

The second, pseudolatin2.jpg, claims that it is using

-B&H-LucidaTypewriter-Medium-R-Normal-Sans-12-120-75-75-M-70-ISO8859-2

Once again, this is not even close.

  Michal
  michal@harddata.com
Comment 1 Michal Jaegermann 2001-02-11 14:26:12 EST
Created attachment 9681 [details]
cyrilic text in supposedly cyrilic font
Comment 2 Michal Jaegermann 2001-02-11 14:27:36 EST
Created attachment 9682 [details]
Latin2 text in claimed latin2 font
Comment 3 Glen Foster 2001-02-12 18:10:49 EST
This defect is considered MUST-FIX for Florence Gold release
Comment 4 Havoc Pennington 2001-02-12 20:02:44 EST
You realize that you can only use fonts with the current locale's encoding - can
you reproduce the problem when LANG is set to a locale with the encoding of
those fonts? If I try to reproduce the problem, I just get:

Gdk-WARNING **: Missing charsets in FontSet creation
Gdk-WARNING **:     ISO8859-1
Gdk-WARNING **:     ISO8859-1

Granted, I'm trying a somewhat different font than the ones you're trying it with.

Comment 5 Michal Jaegermann 2001-02-12 20:52:09 EST
> You realize that you can only use fonts with the current locale's encoding
Not in RH 7 (that for sure because I have right on my screen a window
with LANG=en_US and iso8859-2 font and it works like it should) and not
in beta2 (I think).  If that would get broken in such nasty way that
would be a major breakage and I fail to see for what purpose.
I, and many other people, need very often fonts in different encoding.
Fiddling with a locale because I need to read a text in Cyrilic or in
one of East European languages is not a very exciting prospect.
Defaults are one thing but forcing unwanted choices is something else
altoghether.  Regardless of _warnings_ a computer should not pretend
that it knows better what I really desire.  I does not.
Comment 6 Havoc Pennington 2001-02-12 21:19:48 EST
The problem is that gnome-terminal was using old-style noninternationalized X
font support, which simply uses the character codes from the encoding to index
the font. This does not work properly in multibyte locales, so Japanese, etc.
was broken. It was changed to use the new X multinational font support, which 
requires text to be in the current locale's encoding (this is a 10-year-old open
group design decision, don't flame us). Anyway, so there is no way
gnome-terminal can work with both sets of locales, i.e. it can't work with both
multibyte and Cyrillic/Latin2.

The long-term solution is a move to Unicode, which is in process, and should get
rid of the whole issue. However, that is a while in the future. For this
release, I'll add a configuration option "Enable multibyte support." Note that
this option may be on by default, you will need to toggle it. There simply isn't
a default that always works due to the legacy design of Xlib and locale support
on UNIX.

So it should be MUST-FIX for this release that we get the configuration option
added to gnome-terminal. That option can go away when we move to Unicode.
Comment 7 Michal Jaegermann 2001-02-12 22:20:38 EST
In other words to fix one thing is necessary to break something else.
Sigh!  I indeed do not use any script with multibyte characters but I do
have other needs.  A configuration option will work even if it seems
to fail into "an obscure one - expert category".  I do not know if
intentionally but 'xterm' is not affected by that change (or I should
sit quiet and be happy :-).

A group of users which use multiple iso8859 single byte encodings at
the same time is maybe minimal in North America but is quite
significant in Europe, I am afraid.  Much better a strange option
than a total meltdown.  This change in behaviour should be prominently
mentioned in release notes, I would think.

I am not sure how Unicode would help if I am receiving a text in koi-8
or iso8859-2 (say).  Yes, I know that this is a mess.  Sigh again!
Comment 8 Havoc Pennington 2001-02-12 22:54:23 EST
xterm is a good bit more sophisticated than gnome-terminal, and already does
support Unicode. I'm not sure how they've handled this issue, but they have
probably at least made an attempt, which isn't really true for gnome-terminal.

Even with Unicode there will be some issues, due to all the legacy stuff still
in locale-specific encodings. It was just a broken idea to have locale-specific
encodings, and we will be feeling the pain for years. ;-)
Comment 9 Michal Jaegermann 2001-02-13 12:38:32 EST
So a possible workaround if one needs multibyte encodings as well (I have
Chinese friends :-) would be to have a bunch of menus which launch a subshell,
switch locale and start a gnome-terminal window from there.  Doable if
one is aware what is going on.  There is a --font option there but "the
least surprise principle" is violated.

Tying font encodings to locales sounds like a profoundly broken design.
There is even nothing to ensure that there is one-to-one correspondence
between these two.
Comment 10 Havoc Pennington 2001-02-14 13:22:06 EST
I've done the gnome-core bit of this, there's some gnome-libs work too it appears.
Comment 11 Havoc Pennington 2001-02-15 14:21:21 EST
*** Bug 27809 has been marked as a duplicate of this bug. ***
Comment 12 Leos Bitto 2001-02-15 16:09:45 EST
This is a very interesting problem, however I fully agree with Michal: behaviour
of gnome-terminal in Fisher is completely broken. I live in central Europe, and
we all use ISO-8859-2 here. It worked before - and it doesn't work now. That
hurts. Please fix it for final 7.1.
Comment 13 Havoc Pennington 2001-02-15 16:21:34 EST
As I said already: a) it did NOT work before for Japanese and other multibyte
encodings, it worked only for central Europe b) it is NOT possible to make it
work out-of-the-box for both 
locales at once c) it will be a configuration option, but the default will have
to work for EITHER Japanese or central Europe, not both. That's the best we can
do and it will get done.
Comment 14 Leos Bitto 2001-02-15 16:44:55 EST
I understand. I just wanted to stress the same what Michal tried to - breaking
support for European languages and gainig Japanese is nonsense. Manually
switching between these two options is quite nice solution, thanks for that.
Comment 15 Havoc Pennington 2001-02-19 14:27:40 EST
I was wrong I don't think gnome-libs work is needed, though I can't fully test
it with the setup I have. It should be working now in rawhide (if you turn off
multibyte in preferences). Reopen if not.
Comment 16 vigna 2001-04-30 11:21:07 EDT
This problem is not solved in 7.1, and seems to be related to other problems in
gfontsel etc. If I press "`" or any other ISO-8859-1 character beyond 160 in the
gfontsel demo text input, gfontsel crashes.

Analogously, if I try to write such characters in gnome-terminal I get a space
(but when they are printed, the make white the whole line that follow them).

After a while I realized that disabling multibyte support would fix the problem.
But there is no way to save this option in the configuration file; and it is not
saved by "Save Session". So I have to select it manually for *EACH*
gnome-terminal I open.

I just wish I did not install 7.1.
Comment 17 Leos Bitto 2001-04-30 11:27:12 EDT
I don't remember how does it work in plain RH 7.1 installation, but after I 
installed Ximian Gnome 1.4 gnome-terminal does save the setting (disabling) of 
multibyte support. Get Ximian, it's better than RedHat's desktop anyway!
Comment 18 Havoc Pennington 2001-04-30 11:37:17 EDT
a) the gfontsel bug is a different one in GTK, already reported, unrelated
to this problem; it's fixed by GTK 1.2.10 b) Ximian does not have multibyte
support, thus it works in 8-bit encodings by default but does not work 
in Japanese c) the gnome-terminal multibyte support option saves and restores
just fine for me, please tell us how to reproduce this bug.
Comment 19 vigna 2001-04-30 19:20:06 EDT
After some tweaking, I discovered I had a file named gnome-terminal in my .gnome
directory (I remember having had this since the first GNOME release). The state
of the option was correctly saved in .gnome/Terminal, but the option file read
by gnome-terminal was .gnome/gnome-terminal. Removing the old file solved the
problem (unfortunately it contained the geometry of the terminal, which
apparently cannot be specified in .gnome/Terminal). I guess many other people
could be in the same situation.

Is there any place where all this is documented? I mean, gnome-terminal's
startup sequence, configuration files, etc.
Comment 20 Havoc Pennington 2001-04-30 19:42:59 EDT
It's not documented anywhere. (It's supposed to work from the GUI, editing the
config files isn't really the idea.)

I have a .gnome/Terminal and .gnome/gnome-terminal-XXXXXX files. 
.gnome/Terminal applies to all terminals (and newly-created terminals),
while gnome-terminal-XXXXX is for specific terminal instances. 
However, changing a setting on already-open terminals won't affect other
already-existing terminals, that's true, because the setting is being saved
per-terminal.

This is a semi-feature, but it exists for all the g-t settings, such as color,
etc., not just for this multibyte setting. It isn't clear how it should work;
it's totally reasonable that someone might want Japanese in one terminal and
Latin-1 in another.

If you create a "terminal class" it may help make things more convenient.

Use the color settings to experiment with how it works.

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