VanDyke Software Forums

Go Back   VanDyke Software Forums > SecureCRT 5.1/SecureFX 3.1/VShell 2.6 Beta
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
 
Thread Tools Display Modes
  #1  
Old 03-23-2005, 01:29 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
Minor glitch in 256-color xterm emulation

In Beta 2 I'm seeing a minor glitch when running the xterm test script "256colors2.pl" (Google for links). ^[[48;5;124m displays as rgb(175,0,0) instead of rgb(127,0,0), and ^[[48;5;64m displays as rgb(95,135,0) instead of rgb(42,85,0). (Values are slightly different in the GIF below but you can see the cells with the problem.)

  #2  
Old 03-23-2005, 05:26 PM
mistwolf mistwolf is offline
Registered User
 
Join Date: Mar 2005
Posts: 9
Odd, I see it here OK.

  #3  
Old 04-29-2005, 01:01 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
Update

For what it's worth, I'm still seeing this glitch in build 871. Let me know if there's anything I can provide to help track this down.
  #4  
Old 05-02-2005, 05:48 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,534
Thanks for following up on this. What terminal emulation and font are you using? Could you please post your 256colors2.pl script?

Thanks,
Maureen
  #5  
Old 05-16-2005, 03:51 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
Quote:
Originally Posted by Maureen
Thanks for following up on this. What terminal emulation and font are you using? Could you please post your 256colors2.pl script?
Maureen -- I'm using Xterm emu, ANSI color selected. Font is Bitstream Vera Sans Mono Regular 10. When I switch to Courier New and run 256colors2.pl again, the new output is correct. When I switch back to Bitstream Vera Sans Mono and the screen redraws with the new font, the original output is redrawn with the correct colors. When I run 256colors2.pl one more time, the output is also correct.

Here's the script:

Code:
#!/usr/bin/perl
# Author: Todd Larason <jtl@molehill.org>
# $XFree86: xc/programs/xterm/vttests/256colors2.pl,v 1.1 1999/07/11 08:49:54 dawes Exp $

# use the resources for colors 0-15 - usually more-or-less a
# reproduction of the standard ANSI colors, but possibly more
# pleasing shades

# colors 16-231 are a 6x6x6 color cube
for ($red = 0; $red < 6; $red++) {
    for ($green = 0; $green < 6; $green++) {
        for ($blue = 0; $blue < 6; $blue++) {
            printf("\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\",
                   16 + ($red * 36) + ($green * 6) + $blue,
                   int ($red * 42.5),
                   int ($green * 42.5),
                   int ($blue * 42.5));
        }
    }
}

# colors 232-255 are a grayscale ramp, intentionally leaving out
# black and white
for ($gray = 0; $gray < 24; $gray++) {
    $level = ($gray * 10) + 8;
    printf("\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\",
           232 + $gray, $level, $level, $level);
}


# display the colors

# first the system ones:
print "System colors:\n";
for ($color = 0; $color < 8; $color++) {
    print "\x1b[48;5;${color}m  ";
}
print "\x1b[0m\n";
for ($color = 8; $color < 16; $color++) {
    print "\x1b[48;5;${color}m  ";
}
print "\x1b[0m\n\n";

# now the color cube
print "Color cube, 6x6x6:\n";
for ($green = 0; $green < 6; $green++) {
    for ($red = 0; $red < 6; $red++) {
        for ($blue = 0; $blue < 6; $blue++) {
            $color = 16 + ($red * 36) + ($green * 6) + $blue;
            print "\x1b[48;5;${color}m  ";
        }
        print "\x1b[0m ";
    }
    print "\n";
}


# now the grayscale ramp
print "Grayscale ramp:\n";
for ($color = 232; $color < 256; $color++) {
    print "\x1b[48;5;${color}m  ";
}
print "\x1b[0m\n";
  #6  
Old 05-18-2005, 05:42 PM
jcj's Avatar
jcj jcj is offline
VanDyke Quality Assurance
 
Join Date: Nov 2003
Posts: 65
ErnieLongmire -

I'm not seeing this behavior. I'm using Beta 5, so if you haven't given it a try yet, you might want to download it from:

http://www.vandyke.com/download/securecrt/beta.html

Using Bitstream Vera Sans Mono, with xterm emulation with ANSI color enabled, I get the expected output from 256colors2.pl .

Are you consistently able to reproduce this with Beta 5 ?

Please let us know.

~JcJ
  #7  
Old 03-06-2006, 01:11 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
Still seeing this...!

I've updated my installation to 5.1.0 Build 254 and for some reason I'm still seeing this color-cube glitch. Any suggestions on how I can help you debug this?
  #8  
Old 03-07-2006, 02:57 PM
jjh jjh is offline
VanDyke Customer Support
 
Join Date: Feb 2004
Posts: 799
Hello Ernie.

I tried to reproduce the problem that you are seeing, but I
haven't been able to. I have created an entry for you in
our bug tracking database for our developers to review. We
will contact you when we have something for you to try.

Thank you

JJH
  #9  
Old 05-03-2006, 08:50 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
aha...

I think I've solved this, or at least figured out what's causing it. It looks like under certain circumstances, SCRT will lose a character while processing the escape sequence that loads a color into Xterm's 256-color index table:

ESC ] 4 ; index ; rgb:rval/gval/bval ESC \

When that happens, the default color value for that table position remains unchanged, which can show up as an unexpected color value as shown in the screencap I posted earlier. This happens for me in SCRT versions up through 5.1.0 build 263.

Here's another script that shows the bug for me pretty consistently:

Code:
#!/usr/bin/perl -w

printf "before\n\n"; &show_colors;
printf "press enter to load replacement color table: ";
readline(*STDIN); &load_colors;
printf "after\n\n"; &show_colors;
printf "\x1b[39m\x1b[49m\n\n";

sub load_colors {
  for (my $i = 16; $i <= 255; $i++) {
    printf "\x1b]4;%d;rgb:%2.2x/%2.2x/%2.2x\x1b\\", $i, $i, $i, $i;
    printf "\x1b[38;5;%dm%d: %2.2x/%2.2x/%2.2x\n", $i, $i, $i, $i, $i;
  }
}

sub show_colors {
  for (my $bgix = 0, $fgix = 255; $bgix <= 255; $bgix++, $fgix--) {
    printf "\x1b[48;5;%dm\x1b[38;5;%dm**", $bgix, $fgix;
    if (! (($bgix+1) % 16)) { print "\x1b[48;5;0m\x1b[38;5;255m\n"; }
  }
  printf "\x1b[0m\n";
}
What'll usually happen is that while it's loading the color table (and printing each value as it's loaded) I'll get a couple of output glitches like these:

203: cb/cb/cb
204: cc/cc/cc
;205;rgb:cd/cd/cd205: cd/cd/cd
206: ce/ce/ce
207: cf/cf/cf


with the result that color position 80 keeps its default value, which shows up when the new color table is used.

After running the script you can reset the color table with Edit > Reset from SCRT's menu bar.

Please let me know if this helps you reproduce the behavior.
  #10  
Old 05-04-2006, 10:09 AM
Marlow Weston's Avatar
Marlow Weston Marlow Weston is offline
Registered User
 
Join Date: May 2006
Posts: 1
Send a message via AIM to Marlow Weston
We have tried both scripts with your particular font and a clean restart of the application to no avail.

At this point we would like to view your session.ini and global.ini files to find what terminal settings you are using. Could you please send these files to me at support@vandyke.com with the subject of ATTN: Marlow Forum Thread 617?

Thank you,
Marlow Weston
  #11  
Old 05-04-2006, 01:58 PM
ErnieLongmire ErnieLongmire is offline
Registered User
 
Join Date: Nov 2004
Posts: 18
Sent. Thanks, Marlow.
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 01:23 AM.


copyright 1995-2017 VanDyke Software, Inc.