Re: face colors on 256 colors terminals

[David Kastrup <dak@gnu.org>]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> David Kastrup <dak@gnu.org> writes:
>
>   > I am certain I am missing the context, but is this really
>   > related to the #RRGGBB notation in any manner?  It really looks
>   > awful to me if white gets defined as #ff00ff00ff00, so I'd like
>   > to be as bothersome as to be grateful for some factual
>   > reassurance that we are indeed catering here for a real instead
>   > of a perceived problem, and that the fix in that manner is the
>   > right thing to do.
>
> Well,  there patch has 3 parts. 
>
> Part1:
> The patch to xterm-register-default-colors changes the way the 8bit
> R/G/B values are computed for a 256 color xterm to match what the
> xterm currently does. This part should be correct and
> non-controversial.

Ok.

> Part2:
> xterm-rgb-convert-to-16bit converts an 8bit color value (say Y) to a 16bit
> color. As we discussed, the result can either be Y0 or YY.
> My empirical testing show that there's no visible difference between
> the two. 

If by "visible" you mean "undiscernible by the unadorned eye as long
as no gamma correction is applied", sure.  If by "visible" you mean
"undiscernible by the computer so that the heuristic-mask image
property has a chance of working with an explicit color", we are
talking something entirely different here.

man Xcolor:

[...]

STRUCTURES
	The XColor structure contains:

	typedef struct {
		unsigned long pixel; /* pixel value */
		unsigned short red, green, blue; /* rgb values */
		char flags;         /* DoRed, DoGreen, DoBlue */ 
		char pad;
	} XColor;

	The red, green, and blue values are always in the range 0 to
	65535 inclusive, independent of the number of bits actually
	used in the display hardware.  The server scales these
	values down to the range used by the hardware.  Black is
	represented by (0,0,0),  and white is represented by
	(65535,65535,65535).  In some functions, the flags member
        ^^^^^^^^^^^^^^^^^^^
	controls which of the red, green, and blue members is used
	and can be the inclusive OR of zero or more of DoRed,
	DoGreen, and  DoBlue.

I think it would be appropriate to use the same algorithm as
XParseColor would use on rgb:rrrr/gggg/bbbb: this is explicitly
described as the sort of scaled type that is also in the XColor manual
page.

The XColor manual page explicitly deprecates #rgb notation.

You can also look into

<URL:http://cvs.freedesktop.org/xorg/xc/lib/X11/XRGB.c?view=markup>

to see how they convert colors there.

To quote:

void
_XcmsResolveColor(
    XcmsCCC ccc,
    XcmsColor *pXcmsColor)
/*
 *	DESCRIPTION
 *	    Uses the X Server ResolveColor() algorithm to
 *	    modify values to closest values supported by hardware.
 *	    Old algorithm simply masked low-order bits.  The new algorithm
 *	    has the effect of replicating significant bits into lower order
 *	    bits in order to stretch the hardware value into all 16 bits.
 *
 *	    On a display with N-bit DACs, the "hardware" color is computed as:
 *
 *	    ((unsignedlong)(ClientValue >> (16-N)) * 0xFFFF) / ((1 << N) - 1)
 *		
 *
 *	RETURNS
 *		void.
 */

Now I can't promise that this is the absolutely canonical file for
this functionality: it is what I came across first when trying to
browse the X11 CVS.  It is likely that there are more relevant files
around.  If anybody has the X11 source on his computer, it would
appear that grepping for ResolveColor might be a good idae.

> Part3:
> color-name-rgb-alist contains the colors in rgb.txt converted to
> 16bit. It should use the same conversion as
> xterm-rgb-convert-to-16bit.

I think it should deliver the same results as XParseColor does, right?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum