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: 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 12:13:44 +0100
On 05/05/11 10:17, Steve Purcell wrote:
>
> Would there be a problem if X11 was left as-is, and NS started to interpret #rrggbb as sRGB?
>

Shrug. Insofar as with the current situation one can't expect the
colors to match across the platforms anyway, I guess it wouldn't matter
much. And I do suspect (but n.b. haven't yet checked) that on w32, they
already end up sRGB rather than device-specific, just as a result of
most w32 apis being defined to be sRGB IIRC.

** However, another option, likely quite easily implemented, though,
could  be to just offer a customization as to which of the suitable
predefined spaces to interpret values in on ns, e.g.

(defcustom ns-color-space 'srgb
   "Interpret color specifications in the given color space."
   :type '(choice (const :tag "sRGB" srgb)
                  (const :tag "Compatible with Adobe RGB(1998)" adobe)
                  (const :tag "Calibrated/Generic RGB" generic)
                  (const :tag "Device RGB" device)))

and then use the relevant NSColorSpace classmethods [1] and NSColor
colorWithColorSpace. [2] in the relevant spots, instead of just
colorWithCalibratedRed or colorWithDeviceRed.

That seems to me to be a fairly good option for now?

(A decision would also need to be made as to whether the named color
values bundled with non-x11 emacs are interpreted relative to that
configured space or considered to be sRGB (or one of the others))

> using sRGB on NS would keep emacs unsurprising to OS X folk (to
> paraphrase you).

Thing is, the Apple docs do seem to be encouraging use of their
NSCalibratedRGBColorSpace, and not sRGB, so I'm not actually convinced
sRGB would be unsurprising to OS X folk, at least if other OS X apps
are following those guidelines. The people it primarily wouldn't
surprise might be web and windows folk...

Another little issue is that there _is no_ predefined sRGBColorSpace
available until macosx 10.5+ ! [1]. Do we still support < 10.5 ?


[1] 
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSColorSpace_Class/Reference/Reference.html#//apple_ref/occ/cl/NSColorSpace

[2] 
http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSColor_Class/Reference/Reference.html#//apple_ref/doc/uid/20000353-BBCJCBJA




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.