[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: face colors on 256 colors terminals
From: |
Dan Nicolaescu |
Subject: |
Re: face colors on 256 colors terminals |
Date: |
Wed, 06 Apr 2005 11:26:40 -0700 |
David Kastrup <address@hidden> writes:
> "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.
Hmmm, looking just a few lines above the lines Eli cited from the X
manual you can find this:
The eight primary colors can be represented as:
black rgb:0/0/0
red rgb:ffff/0/0
green rgb:0/ffff/0
blue rgb:0/0/ffff
yellow rgb:ffff/ffff/0
magenta rgb:ffff/0/ffff
cyan rgb:0/ffff/ffff
white rgb:ffff/ffff/ffff
So does this mean that 0xff is gets a special treatment when scaling?
Or it means that the #3000a0007000 example is incorrect?
Does anybody know?
- 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, 2005/04/06
- Re: face colors on 256 colors terminals,
Dan Nicolaescu <=
- 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