After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 306320 - about handle the ascii color
about handle the ascii color
Status: RESOLVED DUPLICATE of bug 400072
Product: vte
Classification: Core
Component: general
0.11.x
Other All
: Normal minor
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-02 20:42 UTC by csj
Modified: 2007-01-31 22:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
select locale eencoding in gnome-terminal (15.93 KB, image/png)
2005-06-08 15:02 UTC, csj
Details
the login screen (29.66 KB, image/png)
2005-06-08 15:03 UTC, csj
Details
login screen use the vte-demo.py (16.41 KB, image/png)
2005-06-08 15:06 UTC, csj
Details
use PCManX and got the correct screen I want (40.75 KB, image/png)
2005-06-08 15:10 UTC, csj
Details

Description csj 2005-06-02 20:42:16 UTC
Please describe the problem:
I use gnome-terminal to telnet some site that use color screen,
like `telnet ptt.cc` and the screen got disordered,
and I use python-vte demo example to try, happened, too
so, I guess something wrong wiith the vte.

like <font color=red>something</font> is expressed in [[1;33m something [[m
but the number between [[ and m should not appear.

Steps to reproduce:
1. I could not read all thing in it.



Actual results:


Expected results:


Does this happen every time?
yes,everytime

Other information:
Comment 1 Michele Baldessari 2005-06-08 14:38:50 UTC
Hi Chungsijay,

it works correctly for me here. Could you give me some more info about your
distro, your setup, machine type and so on? Did you hand-compile vte?
What locale do you use?

And also, if you type the exact command below, do you get a blue "test" message? :

echo -e "\033[34mtest"
Comment 2 csj 2005-06-08 15:00:20 UTC
I did a experiment as follow attachments to express my problem detaily:
Comment 3 csj 2005-06-08 15:02:27 UTC
Created attachment 47445 [details]
select locale eencoding in gnome-terminal

1.
use gnome-termianl and set the encoding to Big5 and  the telnetd server's data
use big5,too
Comment 4 csj 2005-06-08 15:03:56 UTC
Created attachment 47446 [details]
the login screen

use gnome-terminal to `telnet bbs.wretch.cc`
and got the login screen
Comment 5 csj 2005-06-08 15:06:35 UTC
Created attachment 47447 [details]
login screen use the vte-demo.py

2.
use vte-demo.py and added "terminal.set_encoding("big5")"
then `python vte-demo.py` and then `telnet bbs.wretch.cc`
here is the login screen
Comment 6 csj 2005-06-08 15:10:37 UTC
Created attachment 47449 [details]
use PCManX and got the correct screen I want

3.
use PCManX a telnet client that writen in wxWidgets and default use
Big5 encoding; the screen is the right(correct) one.

and if I download the server login screen file,
and `cat Welcome.file`in gnome-terminal , it looks the same with PCManX.
It's so weird.

PCManX:
http://sourceforge.net/projects/pcmanx
Comment 7 csj 2005-06-08 15:31:37 UTC
hi,  Michele Baldessari
I use Ubuntu hoary and I use zh_TW.Utf-8 locale.
vte versions are:
libvte4 1:0.11.12-0ubuntu2
python-vte      1:0.11.12-0ubuntu2

and echo -e "\033[34mtest" I got correct blue "test" in gnome-terminal.
but I have not compile vte handly to test all.
Comment 8 Michele Baldessari 2005-06-09 21:10:37 UTC
Thanks for the info. I can confirm this now.
I believe this is related to some escape sequences not being implemented
correctly (or at all). See bugs:
http://bugzilla.gnome.org/show_bug.cgi?id=155687
http://bugzilla.gnome.org/show_bug.cgi?id=4993

for example. I also add that xterm too fails to parse some escape sequences.
(lowering severity given that it happens in xterm as well)
Comment 9 Michele Baldessari 2005-07-08 09:45:46 UTC
Hi csj,

I think there might be a little bit of progress on this front, if you
apply this patch (from bug #305507):
http://bugzilla.gnome.org/attachment.cgi?id=48803&action=view

Could you apply it and tell me if things look a bit better?

If you have trouble doing so, let me know, and I'll see if I can whip up
some *vte debs for your hoary distro.

thanks
Comment 10 Kjartan Maraas 2005-08-29 08:29:32 UTC
Did you have a chance to test the patch mentioned in #9?
Comment 11 Chris Wilson 2007-01-31 22:54:39 UTC
Another anachronistic dup - the incorrect sequences are of the style '\e[;31;40m'. 

*** This bug has been marked as a duplicate of 400072 ***