can_change_color() tells you whether the terminal can change its color setup. There is a different function called has_colors() that tells you whether the terminal can display colors at all.

I can produce colors on my terminal with the Curses module just fine. I can double the number of available foreground colors by using "BOLD". And I can establish a library of up to 64 color pairs (foreground/background) to refer to as I wish.

What "can_change_color() == 0" tells me is that I cannot use the init_color(...) function to build a custom color beyond the eight that are initially available.

I can get multiple foreground colors on any of eight predetermined background colors on the same screen. But I cannot achieve two foreground colors on true white on the same screen.

Regarding "I suppose there are still uses..." There are indeed. I am building a new UI for a server admin tool that has out-grown its command line interface. Since this tool will only be used via SSH, I am implementing this as a character-based full-window design. The kind of interactive responsiveness we desire makes a CGI solution impractical.

------------------------------------------------------------
"Perl is a mess and that's good because the
problem space is also a mess." - Larry Wall

My mistake on simplifying this. You've obviously dug in quite a bit here ...

As a first course of action I'd still see if it's a terminal/driver limitation or a bug in curses; i.e., get into a mode on the terminal that allows you to type in escape sequences. When I used to do this stuff we wrote a small program for this that set the terminal to raw mode and recognized a 'QUIT' sequence to get back to the shell. That allowed us to try out the documented sequences. As you probably already know, what's documented doesn't always work. At one point we had three configurations for 3 different SCO xterm consoles because they kept introducing new bugs with each driver ... but I digress. Get to this sort of mode, set the background to true white, then try setting foreground colors and see if they work. That should show you if this is a terminal/driver issue or a curses issue.

steves, thanks for your efforts to be of help.

Can the terminal/driver handle multiple colors on a true white background? Yes. A simple "ls" command at the command line in a directory that has several different types of dir entries makes that clear.

Can Curses produce color on a true white background? Again, yes. But as far as I have been able to discover, only through the use of the non-standard color "8" (or some other number higher than 7) in an assume_default_colors() command. This code works:

assume_default_colors(COLOR_RED, 8); # True White bg! Why?
my $win = new Curses;
$win->addstr(0, 0, "Red on White");
[download]

I can find no way to use

init_pair(...); 
... 
attron( $win, COLOR_PAIR(...) );
[download]

to achieve some color on a true white background. And that seems to be what would be needed to give me more than one foreground color on a true white background.

If I were willing to settle for any of the 8 predefined colors as a background, I would be home free. But even the off-white color that Curses calls "WHITE" greatly reduces the contrast and readability of the display.

So in terms of the questions you pose, this all means that it is a Curses/ncurses issue. And that is the way I tried to frame the question in my original post.

Update: I have even tried multiple assume_default_colors(COLOR_SOMETHING, 8) commands -- but no joy. If you want the tutorial on how that fails under various creative strategies, I will be glad to oblige...

I have done a lot of reading and a lot of experimenting/testing and learned a whole bunch about Curses -- everything except the one thing I need to move forward. I am currently looking at other tools... Does anyone know how to get the alternate character set (with box graphics) under Term::ScreenColor? <g>