bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [historical] reasoning behind 88 colors


From: Thomas Dickey
Subject: Re: [historical] reasoning behind 88 colors
Date: Thu, 19 Mar 2020 04:58:16 -0400
User-agent: NeoMutt/20170113 (1.7.2)

On Thu, Mar 19, 2020 at 03:59:08AM -0400, Nick Black wrote:
> [ hey there! this is really more of an xterm question than an
>   ncurses question, but the former doesn't appear to have a
>   mailing list, and last time i asked a question here, i got great
>   answers. so...i hope not to offend ]
> 
> While doing some research for a book I'm writing[0], I came
> across the support for 88 color palettes in xterm and (later)
> at least rxvt. Patch #115 [1] appears to have added the 88-color
> support to xterm (the NCURSES NEWS file mentions 88-color
> terminfo sources by 1999). The Xterm FAQ mentions:
> 
> "88-colors (using the same control sequence) came next, to
>  reduce the amount of memory needed. XTerm stores both foreground
>  and background color indexes for each cell on the screen. That
>  is two bytes, which doubled the amount of memory used by xterm
>  for the scrollback. Reducing that to a single byte allowed a
>  similar scheme using a 4x4x4 cube and a proportionately shorter
>  grayscale ramp."
> 
> My question(s) is(are):
> 
>  (1) How is this a "single byte"? For 88 colors, you need 7

that's an editorial blunder :-(

I don't see email from Steve Wall for that issue (diskspace was a lot more
expensive in 1999), and when expanding the faq in 2016, I probably noticed his
comment which I'd conveyed into the changelog about allocating memory and
misread that into the number of bytes.

Both 88/256 use 2 bytes for color in the character cell, but the color map
would be different (88*88 versus 256*256 combinations).
 
> i guess my question boils down to: what made 88 more appealing
> than either 64 or 128? were 88 colors encodable in fewer than 7
> net bits? did this mechanism not stretch to 96 colors?

The size of the colormap is probably the main issue.
The X server has a lookup table for colors which has limited size.

I recall that running Netscape would cause the colormap to be mostly
allocated for that application, making the colors unavailable to
other applications.

Beyond that, the 88-color layout was intended to fit with the same
idea as in 256-colors: 16-color set, along with a cube and then a
grayscale set.  I suppose one could come up with a 5x5x5 scheme:

        88      157     256
        -------------------
        16      16      16      ANSI/AIX
        64      125     216     cube
        8       16      24      grayscale "ramp"

But the savings in the colormap wouldn't be as much:

        colors  size    bits
        88      7744    13
        157     24649   15
        256     65536   16
                ^^^important!

-- 
Thomas E. Dickey <address@hidden>
https://invisible-island.net
ftp://ftp.invisible-island.net

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]