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

Previous Next

Package: emacs;

Reported by: Steve Purcell <steve <at> sanityinc.com>

Date: Fri, 1 Apr 2011 10:02:01 UTC

Severity: normal

Tags: moreinfo

Found in version 24.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Steve Purcell <steve <at> sanityinc.com>
To: David De La Harpe Golden <david <at> harpegolden.net>
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: Wed, 4 May 2011 20:31:35 +0100
On 4 May 2011, at 17:58, David De La Harpe Golden wrote:

> ** OTOH it's possible to imagine the emacs project deciding - rather backward incompatibly for x11 users mind you - that, say, "#RRGGBB" syntax color strings in emacs on all platforms are actually to be considered to be in the sRGB colorspace henceforth, like they are officially in html/css.


This would be a great step forward, IMO: sRGB is the standard on the web and on most displays, and a clear definition of Emacs' colorspace would be a Good Thing.


> So a more backward-compat friendly thing to do than using #RRGGBB for srgb, might be to add support within emacs for an "sRGB:<red>/<green>/<blue>"  syntax by analogy with the standard XParseColor() ones, and handle it internally


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?

-Steve



This bug report was last modified 3 years and 32 days ago.

Previous Next


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