emacs-devel
[Top][All Lists]
Advanced

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

Re: sRGB color support in NS port [PATCH]


From: Steve Purcell
Subject: Re: sRGB color support in NS port [PATCH]
Date: Sun, 22 Dec 2013 13:55:37 +0000

On 22 Dec 2013, at 00:31, Stephen J. Turnbull <address@hidden> wrote:

> David De La Harpe Golden writes:
> 
>> 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.



So given the general tone of support for treating #RGB as sRGB, can we (as a 
first small step) agree to enable Jan’s new sRGB option for NS by default?

-Steve


reply via email to

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