Re: sRGB color support in NS port [PATCH]

[David De La Harpe Golden]

On 22/12/13 00:31, Stephen J. Turnbull wrote:

> +0.9  IWBNI Emacs also provided a way to get the effect of the old
> names.

Not impossible, one could imagine a list of resolvers, or a scope prefix.

Though bear in mind there are apparently (sayeth wikipedia) only ~4 real 
conflicts (though I suppose not rare colors: gray, green, maroon, 
purple) [1] (at least ignoring user-defined named colors), so it may not 
be worth it, especially as you could still set the x-like color by rgb 
triple.

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

Well, what's more important...  That #0DEA84 is the same color on 
x11/mac/ns/w32 emacs or the same color in x11 emacs/xterm/xclock...

Mind you, I do now belatedly recall: last I heard/understood of plans in 
the area (some time ago now), was that a color-managing compositor 
plugin component of the "new" color management stack [2] would "soon" 
mean that any such x11 nominally-device-dependent rgb colors presented 
by said-new-stack unaware clients _would_ nonetheless ultimately tend to 
end up being interpreted as sRGB on x11 too (!), despite my earlier 
claims & their historical definition. Though I don't know how widely 
adopted that infrastructure is yet [3].

[1] http://en.wikipedia.org/wiki/X11_colors#Color_name_clashes
[2] http://www.oyranos.org/compicc/
[3] http://sourceforge.net/p/oyranos/feature-requests/2/#d625