[Top][All Lists]

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

bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctl

From: David De La Harpe Golden
Subject: bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa))
Date: Thu, 05 May 2011 09:14:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110402 Icedove/3.1.9

On 04/05/11 20:31, Steve Purcell wrote:

Adding a new "sRGB:r/g/b" syntax seems less clean
if you'd have to handle it explicitly before passing it
> to XParseColor, why not just make it the default?

Remember, the XParseColor() system remains in wide use by other
x11 apps.  If emacs used "#RRGGBB" in an incompatible manner, we'd then
be getting bugs about the colors not matching anymore between emacs
and  other apps on x11 when people use the "same" values, e.g.
launching both
xterm -fg '#fedcba' -bg '#123456'
emacs -fg '#fedcba' -bg '#123456'
one would expect them to look the same.

I think keeping emacs unsurprising to x11 folk is good, given x11's use
as the main free gui...

Another option in the design space could be to have an "emacs:" super-
prefix that does colors in a standard emacs space* e.g.
"emacs:#334455". Emacs could also bundle its named-colors table (it
already does for non-x11 use) declared in the space, so you could do
"emacs:Tomato", while anything not prefixed that way is passed through
to XParseColor().  Then e.g. "emacs:#RRGGBB" would be potentially
different to an "#RRGGBB", "emacs:Tomato" potentially different to

Or you could flip that, and have  an "x11:" super-prefix that means
"pass the remainder through to XParseColor()", while unprefixed is
handled in the emacs space, but people will, as above, expect command
line args and X resources on x11 to be interpreted in the x11 manner,
so such a prefix might then have to be implicitly added for those cases.

Either way, that's a bit different to just having srgb: - it handles
named colors in a cross-platform manner, and leaves it possible for
emacs to support more syntaxes internally - Hey, I suppose supporting
the CSS3-color syntax [1] in general would be neat, either prefixed or
unprefixed. Have to remember that the x11 (and therefore historic emacs) color names and html/css color names clash somewhat, sigh [2]

...Or we could stop using string specs and have an actual color type,
maybe with strings in color slots interpreted backward compatibly...

* presumably srgb in practice, while it's sometimes criticised, it's a
reasonable choice, it is a text editor we're talking about.

[1] http://www.w3.org/TR/css3-color/

[2] http://en.wikipedia.org/wiki/X11_color_names#Color_names_that_clash_between_X11_and_HTML.2FCSS

reply via email to

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