emacs-devel
[Top][All Lists]
Advanced

[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? 



reply via email to

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