From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: face colors on 256 colors terminals Date: Wed, 06 Apr 2005 11:26:40 -0700 Message-ID: <200504061826.j36IQgAH014283@scanner2.ics.uci.edu> References: <200504060817.j368HDAH019106@scanner2.ics.uci.edu> <01c53acd$Blat.v2.4$7c0f2080@zahav.net.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112813315 14869 80.91.229.2 (6 Apr 2005 18:48:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Apr 2005 18:48:35 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 06 20:48:32 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DJFYW-0008Ix-2r for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2005 20:47:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJF7f-0004kC-9C for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2005 14:19:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DJF60-0004Ca-Id for emacs-devel@gnu.org; Wed, 06 Apr 2005 14:17:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJF5z-00042g-2q for emacs-devel@gnu.org; Wed, 06 Apr 2005 14:17:43 -0400 Original-Received: from [128.195.1.36] (helo=scanner2.ics.uci.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DJFGn-00034b-4y; Wed, 06 Apr 2005 14:28:53 -0400 Original-Received: from vino.ics.uci.edu (dann@vino.ics.uci.edu [128.195.11.198]) by scanner2.ics.uci.edu (8.12.10/8.12.10) with ESMTP id j36IQgAH014283; Wed, 6 Apr 2005 11:26:42 -0700 (PDT) Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "Wed, 06 Apr 2005 19:36:27 +0200") Original-Lines: 73 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-99.723, required 5, FB_CONST_9, TW_XF, USER_IN_WHITELIST) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:35651 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35651 David Kastrup writes: > "Eli Zaretskii" writes: > > >> From: Dan Nicolaescu > >> 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?