Minor glitch in 256-color xterm emulation

[ErnieLongmire]

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.)

[mistwolf]

Odd, I see it here OK.

[ErnieLongmire]

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.

[Maureen]

Thanks for following up on this. What terminal emulation and font are you using? Could you please post your 256colors2.pl script?

Thanks,
Maureen

[ErnieLongmire]

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:

#!/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";

[jcj]

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

[ErnieLongmire]

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?

[jjh]

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

[ErnieLongmire]

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:

#!/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.

[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

[ErnieLongmire]

Sent. Thanks, Marlow.