"Eli Zaretskii" <[EMAIL PROTECTED]> writes: >> From: Dan Nicolaescu <[EMAIL PROTECTED]> >> 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 _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel