[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sRGB color support in NS port [PATCH]

From: David De La Harpe Golden
Subject: Re: sRGB color support in NS port [PATCH]
Date: Sun, 22 Dec 2013 21:20:41 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]