[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[historical] reasoning behind 88 colors
From: |
Nick Black |
Subject: |
[historical] reasoning behind 88 colors |
Date: |
Thu, 19 Mar 2020 03:59:08 -0400 |
[ 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
bits. Even if this was paired with 8 or 16 colors already being
stored elsewhere, and only 72/80 "new" ones needed
representation, that still can't be done in 6 bits. 256 colors
would be a single byte, but the FAQ specs two, suggesting this
spec included both front and back. In that case, you still need
12 bits, i.e. three nibbles, i.e. 75% of two bytes. Unless you
only had 1 bit devoted to background color, I don't understand
this.
(2) Even if it is just a net savings of 1 bit per dimension,
why 88 rather than 128? Was this merely because the 4x4x4 cube
was the biggest that could fit in 7 bits, assuming the
preexisting 16 aixterm colors? If so, why not use the other 24
colors for greys, as opposed to only 8? 8 doesn't even seem to
be proportional; 4/6 == 2/3, suggesting 16 greyscales (which
would fit comfortably with 16 + 64 in 7 bits).
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?
Stephen P Wall, do you read this list? :)
thanks! apologies if this is unsuiable for bugs-ncurses.
--nick
[0] https://nick-black.com/dankwiki/index.php/Hacking_The_Planet!_with_Notcurses
(note that this is still very much in draft mode. the relevant
material is in chapter 6 and appendix a.)
[1] https://invisible-island.net/xterm/xterm.log.html#xterm_115
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
- [historical] reasoning behind 88 colors,
Nick Black <=