Re: sRGB color support in NS port [PATCH]

[David De La Harpe Golden]

On 21/12/13 17:37, Steve Purcell wrote:

> On Windows, the RGB colour literals will be assumed to be coordinates within 
> its default sRGB space.
> On OS X, emacs will claim that they are in the vague “calibrated” 
space, which is not sRGB, so
> they will automatically look different between the two platforms. 
This seems like a shortcoming to
> me, and it’s not clear to me that making the color space a user 
preference is the correct fix, at
> least if the default is the calibrated space.


> But maybe I've missed something and/or my logical understanding of the
> situation is flawed, and I’d be happy to find out how. :-)
>

Well, doesn't change things much, but I'm not sure "[Apple] Generic RGB" 
is as vague as you think. No, it's not the same as either historical 
"Apple RGB" or of course sRGB, but doesn't quite look to me like it's 
just some "a generic RGB color space" in the sense the wikipedia 
absolute colorspaces article you previously linked meant. [1][2]

But Emacs is presently primarily a (coding-friendly) text-editor 
(leaving aside recent discussions about wysiwig word processing).  So 
sRGB, whatever its failings, seems fairly adequate for emacs' normal 
duties. sRGB is obviously fine for ordinary text-editing and coding, you 
don't need wide gamut for a few different syntax highlights, and it's 
actively beneficial for the webdev guys.  And cross-platform consistency 
of emacs color themes might be something a lot of users want.

If emacs devs were to just up and declare:

"""On color-management-capable platforms, where possible emacs shall 
default to sRGB for interpretation of rgb triples without any explicit 
color space declaration."""

(and maybe a related: """emacs will adopt the static list of 
HTML/CSS/SVG named-color definitions where applicable, superseding any 
historical X11/emacs named-color definitions  - and user-defined 
named-colors on platforms that support them (i.e. X11) - where they 
clash""" [3][4])

...that's a reasonable enough project decision if you ask me. Not sure 
I'd bother even including an option to switch the default color space 
for such unqualified triples to anything else (just maybe note that at 
some future date a larger component value range may become valid, for 
scRGB).

But do bear in mind X11 has history here. The full X11 color 
specification string syntax that is fundamentally where emacs gets its 
notions of how to interpret color specifications has long included 
support for explicitly device-independent colors with a color space 
qualification prefix like e.g. "CIEXYZ:x/y/z".   Though no-one ever 
added support for "srgb:r/g/b" to date which is a shame, and it may be 
difficult to find X people who care to do so now, with so many treating 
X as legacy and looking to Wayland (and I imagine that'll almost 
certainly default to sRGB, though haven't checked).

Unfortunately, "#RRGGBB" and "rgb:r/g/b" and "rgbi:r/g/b" are all 
_explicitly defined_ to be in the vague device-dependent space in the 
X11 syntax (man XParseColors). So if emacs DOES decide the above, X11 
color handling code will need work: X11 emacs wouldn't be able to just 
hand off all color strings to X11 for resolution any more, it would have 
to treat color-space-unqualified triples (and perhaps named colors) 
differently to X11 itself.

(The alternative, changing ns/mac and w32 to treat #RRGGBB as 
device-dependent and require explicit color space prefixing for anything 
else for full "feature"-compatibility with X11, doesn't seem all that 
attractive, but would also be consistent... I mention it for completeness)




[1] https://developer.apple.com/library/mac/qa/qa1430/_index.html
[2] https://github.com/gnachman/iTerm2/pull/149

[3]http://en.wikipedia.org/wiki/Web_color
[4]http://en.wikipedia.org/wiki/X11_color_names