Re: sRGB color support in NS port [PATCH]

[Steve Purcell]

Hi David,

On 21 Dec 2013, at 20:26, David De La Harpe Golden <address@hidden> 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