bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa))

[Steve Purcell]

On 10 Apr 2011, at 23:38, Chong Yidong wrote:

> Steve Purcell <steve@sanityinc.com> writes:
> 
>> what's the color behavior on other window-systems? I haven't had the
>> opportunity to compare. It does seem like your fix would be more
>> likely to give the results a user would want.
> 
> On X, we just pass color names to Xlib functions like XParseColor as
> simple RGB, i.e. not specifying any particular color space, letting that
> be chosen by X.  I don't know how this choice is made; the Xlib docs
> simply say that the color space is device-dependent.  In general, I
> think we use whatever color space happens to be the system default.
> 
> I am not familiar with the code in question, but from what I can tell
> the NS code always uses NSCalibratedRGBColorSpace, which indicates that
> using colorWithCalibratedRed to specify RGB components ought to do the
> right thing.  I don't know why it doesn't.


I'm told by a user with access to an Emacs on X11 that hex colors on that 
window system display in what appears to be the same way; that is, the hex 
colors applied by Emacs do not correspond to the resultant sRGB display colors, 
but rather to a generic RGB color space which is translated by the host system 
into that sRGB color space.

I guess it'd be ideal if the hex colors entered in Emacs corresponded with the 
host window system's notion of hex colors, but it could also be argued that the 
existing behavior is at least consistent across platforms.

The downside of the current system is that it's not possible to directly apply 
to Emacs colors that have been found on the web or via a color-picker tool on 
the host machine.