'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
Created attachment 9681 [details] cyrilic text in supposedly cyrilic font
Created attachment 9682 [details] Latin2 text in claimed latin2 font
This defect is considered MUST-FIX for Florence Gold release
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.
> 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.
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.
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!
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. ;-)
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.
I've done the gnome-core bit of this, there's some gnome-libs work too it appears.
*** Bug 27809 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.
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!
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.
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.
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.