Red Hat Bugzilla – Bug 68651
Add a "choose source encoding" menu to gnome-terminal
Last modified: 2007-03-26 23:54:48 EDT
Description of Problem:
Not only new gnome destroys a basic ability to have on a screen terminal
windows side-by-side terminal windows using fonts with different encodings
but even elementary font handling is FUBAR.
Attached is an example of a small file in koi8-r encoding and two screenshots.
The first shows how this file is displayed in a correct class gnome-terminal
from gnome-core-220.127.116.11-54 without any changes in a general session setup.
The second one shows how gnome-terminal from Limbo looks like when the
same file is used and "Russian" session is picked up. The later has
an effect of randomly translating various menus and message (quite undesirable
in my case) but it seems to have a null effect where it really counts.
Fonts used in a terminal do have a version with koi8-r encoding but this
seems to be ignored. The same mess occures with iso-8859-2 fonts, at least,
but effects are visually more subtle. :-)
Created attachment 65044 [details]
A short text in koi8-r encoding
Created attachment 65045 [details]
How this text looks on a sane display
Created attachment 65046 [details]
How designers of Gnome2 seem think that you should see it
what is your locale?
If your locale is koi8 then the text should have been converted,
I'm not sure what's wrong.
If your locale is not koi8, then the only fix is to have a manual "set encoding"
menu as in Mozilla. Which is perhaps worthwhile. Nothing to do with fonts though.
I picked up "Russian" session from a login menu. You can see effects of this
in a tool bar of a terminal frame as presented one of pictures. What should
or should not be converted I have no idea and, unfortunately, I do not have
any control over it. Actually there is nothing to "convert"; only proper
fonts for a display should be used. I strongly suspect that in reality some
"conversion" kicked in and pitiful results you can observe on an attached
Moreover if you are thinking 'iconv' then this program is truly anal-retentive
and is using then slightest provocations to bail-out. In "real life" text in
other encodings often contain extra characters from ASCII. Yes, I know that
this is often not "correct" in some sense but I do not have the slightest degree
of a control over it. For this test I picked up something which is
"pure koi8-r" not to introduce extra factors.
Indeed, allowing to pick up an encoding in a profile and no "conversions"
seems like the only sane thing to do.
The whole point of a "choose encoding" menu is to do conversion from that
encoding, so it doesn't make sense to say you want such a menu but no
I am not that interested at this moment what is going on under-the-hood.
I only know from an experience that when 'iconv' is getting involved this
usually spells trouble. I also know that in the currently released software
things do work (maybe by an accident but so what?) and what is in
beta is at this time plain broken.
Proposed UI here: http://pobox.com/~hp/terminal-encoding.png
Marking the head of the priority queue with priority high
*** Bug 75326 has been marked as a duplicate of this bug. ***
Ah, this should be done in rawhide. There's a menu Terminal->Character Coding