Re: sRGB color support in NS port [PATCH]

[Steve Purcell <steve@sanityinc.com>]

Hi David,

On 21 Dec 2013, at 20:26, David De La Harpe Golden <david@harpegolden.net> wrote:
> 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.


Yes, there are a *lot* of themes out there, and some of the most popular contain outrageous and unreliable hacks to compensate for the inconsistent interpretation of rgb literals on different emacs platforms:

https://github.com/sellout/emacs-color-theme-solarized/blob/master/solarized-definitions.el#L43

Others assume (more sanely) that OS X users have an sRGB patch compiled into their emacs, so that the theme will look the same as on Windows, which is (as you note) the only other major emacs platform to consistently handle plain #RRGGBB colours.


> 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).


Yes, I also believe such a declaration would be extremely helpful, and a big improvement on the current situation.


> 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).


Yes, it does look like Wayland plan to default to sRGB:

http://www.chaosreigns.com/wiki/Wayland_design_documents_and_drawing


> 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.


Right, so in summary, without any immediate changes emacs on X11 would be unaffected by any standardisation on sRGB, but over time further work could be undertaken on that platform to ensure that those “plain” RGB colour specs are interpreted as well-defined sRGB colours.  Makes sense.


> (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)


Agreed.

-Steve