From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: face colors on 256 colors terminals Date: Thu, 07 Apr 2005 12:23:10 +0200 Message-ID: References: <200504060817.j368HDAH019106@scanner2.ics.uci.edu> <01c53acd$Blat.v2.4$7c0f2080@zahav.net.il> <200504061752.j36HqSAH012245@scanner2.ics.uci.edu> <01c53aea$Blat.v2.4$16ee4740@zahav.net.il> <200504062350.j36NoAAH028834@scanner2.ics.uci.edu> <200504070514.j375EBAH009933@scanner2.ics.uci.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1112870785 13066 80.91.229.2 (7 Apr 2005 10:46:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 7 Apr 2005 10:46:25 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 07 12:46:22 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DJUW7-0000bR-IB for ged-emacs-devel@m.gmane.org; Thu, 07 Apr 2005 12:45:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJU5P-0002Sb-4N for ged-emacs-devel@m.gmane.org; Thu, 07 Apr 2005 06:18:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DJTib-0003Hu-Ki for emacs-devel@gnu.org; Thu, 07 Apr 2005 05:54:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DJTia-0003HU-NL for emacs-devel@gnu.org; Thu, 07 Apr 2005 05:54:33 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DJUAw-00065R-7s for emacs-devel@gnu.org; Thu, 07 Apr 2005 06:23:50 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DJUA1-0005bZ-KJ; Thu, 07 Apr 2005 06:22:54 -0400 Original-To: Dan Nicolaescu In-Reply-To: <200504070514.j375EBAH009933@scanner2.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 06 Apr 2005 22:14:08 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:35688 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35688 Dan Nicolaescu writes: > David Kastrup writes: > > > I am certain I am missing the context, but is this really > > related to the #RRGGBB notation in any manner? It really looks > > awful to me if white gets defined as #ff00ff00ff00, so I'd like > > to be as bothersome as to be grateful for some factual > > reassurance that we are indeed catering here for a real instead > > of a perceived problem, and that the fix in that manner is the > > right thing to do. > > Well, there patch has 3 parts. > > Part1: > The patch to xterm-register-default-colors changes the way the 8bit > R/G/B values are computed for a 256 color xterm to match what the > xterm currently does. This part should be correct and > non-controversial. Ok. > Part2: > xterm-rgb-convert-to-16bit converts an 8bit color value (say Y) to a 16bit > color. As we discussed, the result can either be Y0 or YY. > My empirical testing show that there's no visible difference between > the two. If by "visible" you mean "undiscernible by the unadorned eye as long as no gamma correction is applied", sure. If by "visible" you mean "undiscernible by the computer so that the heuristic-mask image property has a chance of working with an explicit color", we are talking something entirely different here. man Xcolor: [...] STRUCTURES The XColor structure contains: typedef struct { unsigned long pixel; /* pixel value */ unsigned short red, green, blue; /* rgb values */ char flags; /* DoRed, DoGreen, DoBlue */ char pad; } XColor; The red, green, and blue values are always in the range 0 to 65535 inclusive, independent of the number of bits actually used in the display hardware. The server scales these values down to the range used by the hardware. Black is represented by (0,0,0), and white is represented by (65535,65535,65535). In some functions, the flags member ^^^^^^^^^^^^^^^^^^^ controls which of the red, green, and blue members is used and can be the inclusive OR of zero or more of DoRed, DoGreen, and DoBlue. I think it would be appropriate to use the same algorithm as XParseColor would use on rgb:rrrr/gggg/bbbb: this is explicitly described as the sort of scaled type that is also in the XColor manual page. The XColor manual page explicitly deprecates #rgb notation. You can also look into to see how they convert colors there. To quote: void _XcmsResolveColor( XcmsCCC ccc, XcmsColor *pXcmsColor) /* * DESCRIPTION * Uses the X Server ResolveColor() algorithm to * modify values to closest values supported by hardware. * Old algorithm simply masked low-order bits. The new algorithm * has the effect of replicating significant bits into lower order * bits in order to stretch the hardware value into all 16 bits. * * On a display with N-bit DACs, the "hardware" color is computed as: * * ((unsignedlong)(ClientValue >> (16-N)) * 0xFFFF) / ((1 << N) - 1) * * * RETURNS * void. */ Now I can't promise that this is the absolutely canonical file for this functionality: it is what I came across first when trying to browse the X11 CVS. It is likely that there are more relevant files around. If anybody has the X11 source on his computer, it would appear that grepping for ResolveColor might be a good idae. > Part3: > color-name-rgb-alist contains the colors in rgb.txt converted to > 16bit. It should use the same conversion as > xterm-rgb-convert-to-16bit. I think it should deliver the same results as XParseColor does, right? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum