GNU bug report logs - #8402
24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)

Previous Next

Full log

View this message in rfc822 format

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Steve Purcell <steve <at> sanityinc.com>
Cc: 8402 <at> debbugs.gnu.org, Erik Andrejko <eandrejko <at> gmail.com>, Chong Yidong <cyd <at> stupidchicken.com>
Subject: bug#8402: Acknowledgement (24.0.50;	Hex colors are not rendered correctly on OS X (Cocoa))
Date: Thu, 05 May 2011 09:14:54 +0100

On 04/05/11 20:31, Steve Purcell wrote:

> Adding a new "sRGB:r/g/b" syntax seems less clean
> if you'd have to handle it explicitly before passing it
> to XParseColor, why not just make it the default?
>

Remember, the XParseColor() system remains in wide use by other
x11 apps.  If emacs used "#RRGGBB" in an incompatible manner, we'd then
be getting bugs about the colors not matching anymore between emacs
and  other apps on x11 when people use the "same" values, e.g.
launching both
xterm -fg '#fedcba' -bg '#123456'
emacs -fg '#fedcba' -bg '#123456'
one would expect them to look the same.

I think keeping emacs unsurprising to x11 folk is good, given x11's use
as the main free gui...

Another option in the design space could be to have an "emacs:" super-
prefix that does colors in a standard emacs space* e.g.
"emacs:#334455". Emacs could also bundle its named-colors table (it
already does for non-x11 use) declared in the space, so you could do
"emacs:Tomato", while anything not prefixed that way is passed through
to XParseColor().  Then e.g. "emacs:#RRGGBB" would be potentially
different to an "#RRGGBB", "emacs:Tomato" potentially different to
"Tomato".

Or you could flip that, and have  an "x11:" super-prefix that means
"pass the remainder through to XParseColor()", while unprefixed is
handled in the emacs space, but people will, as above, expect command
line args and X resources on x11 to be interpreted in the x11 manner,
so such a prefix might then have to be implicitly added for those cases.

Either way, that's a bit different to just having srgb: - it handles
named colors in a cross-platform manner, and leaves it possible for
emacs to support more syntaxes internally - Hey, I suppose supporting
the CSS3-color syntax [1] in general would be neat, either prefixed or
unprefixed.  Have to remember that the x11 (and therefore historic 
emacs) color names and html/css color names clash somewhat, sigh [2]

...Or we could stop using string specs and have an actual color type,
maybe with strings in color slots interpreted backward compatibly...

* presumably srgb in practice, while it's sometimes criticised, it's a
reasonable choice, it is a text editor we're talking about.

[1] http://www.w3.org/TR/css3-color/

[2] 
http://en.wikipedia.org/wiki/X11_color_names#Color_names_that_clash_between_X11_and_HTML.2FCSS

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.