Re: sRGB color support in NS port [PATCH]

[Stephen J. Turnbull]

David De La Harpe Golden writes:

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

+1

Please, let's stop trying to make core Emacs suitable for tasks that
other projects have spent man-decades (in some cases, man-centuries)
on.

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

+0.9  IWBNI Emacs also provided a way to get the effect of the old
names.  I doubt anybody is going to notice the difference between sRGB
and RGB (except maybe themers who are matching WMs that use a
different color space).  But if names conflict, anything can happen.
(It was years before I realized that "cyan" was on the G side of B,
and a bit embarrassing when my nose was rubbed in the fact. :-)

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

I think the thing to do here is to steal "#RGB" for sRGB, and provide
a trivial textual translator for those strings, plus one that reads in
rgb.txt as device-dependent.

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

It doesn't seem very future-proof.

Steve