[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: face colors on 256 colors terminals
From: |
David Kastrup |
Subject: |
Re: face colors on 256 colors terminals |
Date: |
Wed, 06 Apr 2005 19:36:27 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
"Eli Zaretskii" <address@hidden> writes:
>> From: Dan Nicolaescu <address@hidden>
>> Date: Wed, 06 Apr 2005 01:17:11 -0700
>>
>> This comment in tty-colors.el:tty-color-standard-values
>>
>> ;; Translate the string "#XXYYZZ" into a list
>> ;; of numbers (XX YY ZZ). If the primary colors
>> ;; are specified with less than 4 hex digits,
>> ;; the used digits represent the most significant
>> ;; bits of the value (e.g. #XYZ = #X000Y000Z000).
>>
>> does not seem to match the way the `color-name-rgb-alist' seem to have
>> been created from the values in rgb.txt.
>> A random example:
>> >From color-name-rgb-alist:
>> ("lavenderblush" 65535 61680 62965)
>> ^^^^ ^^^^ ^^^^
>> 0xffff 0xf0f0 0xf5f5
>>
>> >From rgb.txt: lavender blush 255 240 245
>> 0xff 0xf0 0xf5
>> So the 8 to 16 bit conversion seems use the same byte value for both
>> the high and low byte value.
>
> The comment you cited reflects what I found in the X documentation.
> Here, for example, is an excerpt from the X(7) man page on a Debian
> GNU/Linux box (fencepost.gnu.org):
>
> For backward compatibility, an older syntax for RGB Device
> is supported, but its continued use is not encouraged.
> The syntax is an initial sharp sign character followed by
> a numeric specification, in one of the following formats:
>
> #RGB (4 bits each)
> #RRGGBB (8 bits each)
> #RRRGGGBBB (12 bits each)
> #RRRRGGGGBBBB (16 bits each)
>
> The R, G, and B represent single hexadecimal digits. When
> fewer than 16 bits each are specified, they represent the
> most-significant bits of the value (unlike the "rgb:" syn-
> tax, in which values are scaled). For example, #3a7 is
> the same as #3000a0007000.
>
> So I think the code in tty-colors.el is correct in this matter. It
> is, however, possible that the RGB values in color-name-rgb-alist were
> incorrectly scaled from 8-bit variants, and need to be amended.
Actually, it does not make sense to scale in that way. #3a7 really
should be the same as #3333aaaa7777, so that #fff is the same as
#ffffffffffff, pure white.
Somebody should tell the X people to do that. I just have no idea who
to tell, and it would appear that there is a bit of previous art that
might rely on the current behavior...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
- face colors on 256 colors terminals, Dan Nicolaescu, 2005/04/06
- Re: face colors on 256 colors terminals, Eli Zaretskii, 2005/04/06
- Re: face colors on 256 colors terminals,
David Kastrup <=
- Re: face colors on 256 colors terminals, Dan Nicolaescu, 2005/04/06
- Re: face colors on 256 colors terminals, James Cloos, 2005/04/07
- Re: face colors on 256 colors terminals, Dan Nicolaescu, 2005/04/07
- Re: face colors on 256 colors terminals, Eli Zaretskii, 2005/04/08
- Re: face colors on 256 colors terminals, Dan Nicolaescu, 2005/04/08
- Re: face colors on 256 colors terminals, Eli Zaretskii, 2005/04/09
Re: face colors on 256 colors terminals, Dan Nicolaescu, 2005/04/06