[Top][All Lists]

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

Re: sRGB color support in NS port [PATCH]

From: Stephen J. Turnbull
Subject: Re: sRGB color support in NS port [PATCH]
Date: Sun, 22 Dec 2013 09:31:26 +0900

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.


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

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


reply via email to

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