Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 68651

Summary: Add a "choose source encoding" menu to gnome-terminal
Product: [Retired] Red Hat Linux Reporter: Michal Jaegermann <michal>
Component: gnome-terminalAssignee: Havoc Pennington <hp>
Status: CLOSED RAWHIDE QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: high    
Version: 8.0CC: mitr, nalin, otaylor, shishz, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-01-02 15:58:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 67218, 79579    
Attachments:
Description Flags
A short text in koi8-r encoding
none
How this text looks on a sane display
none
How designers of Gnome2 seem think that you should see it none

Description Michal Jaegermann 2002-07-12 03:10:03 UTC
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-1.4.0.4-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. :-)

Comment 1 Michal Jaegermann 2002-07-12 03:11:03 UTC
Created attachment 65044 [details]
A short text in koi8-r encoding

Comment 2 Michal Jaegermann 2002-07-12 03:12:11 UTC
Created attachment 65045 [details]
How this text looks on a sane display

Comment 3 Michal Jaegermann 2002-07-12 03:13:26 UTC
Created attachment 65046 [details]
How designers of Gnome2 seem think that you should see it

Comment 4 Havoc Pennington 2002-07-12 15:42:08 UTC
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.

Comment 5 Michal Jaegermann 2002-07-12 16:08:53 UTC
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
picture.

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.


Comment 6 Havoc Pennington 2002-07-12 16:24:19 UTC
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
conversions. ;-)

Comment 7 Michal Jaegermann 2002-07-12 22:29:04 UTC
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.

Comment 8 Havoc Pennington 2002-07-14 22:14:36 UTC
Proposed UI here: http://pobox.com/~hp/terminal-encoding.png

Comment 9 Havoc Pennington 2002-07-29 16:25:44 UTC
Marking the head of the priority queue with priority high

Comment 10 Havoc Pennington 2002-10-07 14:24:02 UTC
*** Bug 75326 has been marked as a duplicate of this bug. ***

Comment 11 Havoc Pennington 2003-01-02 15:58:46 UTC
Ah, this should be done in rawhide. There's a menu Terminal->Character Coding
in gnome-terminal.