bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Wed, 04 May 2011 17:58:16 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Icedove/3.1.9

On 10/04/11 23:38, Chong Yidong wrote:
Steve Purcell<address@hidden>  writes:

what's the color behavior on other window-systems? I haven't had the
opportunity to compare. It does seem like your fix would be more
likely to give the results a user would want.

On X, we just pass color names to Xlib functions like XParseColor as
simple RGB,

To nitpick: AFAIK we pass the /color string names themselves/ to XParseColor() to resolve them, don't we? - color name -> color mapping is not internally handled by emacs on X11.

You can even define your own named colors on x11 over and above the familiar historic rgb.txt set if you fiddle about e.g.

$ cat ~/.xcms.txt
XCMS_COLORDB_START 0.1
Blobby  rgb:7fe2/ffe1/331a
XCMS_COLORDB_END
$ export XCMSDB=/home/david/.xcms.txt
$ emacs

- Now "Blobby" is an additional named color like "green".

i.e. not specifying any particular color space, letting that
be chosen by X.

We-ell. See the XParseColor() manpage, section COLOR NAMES [1] - you
can explicitly specify various device-independent colorspaces, and they do in principle work if you put them into a color field in emacs on x11, because emacs just passes the string straight on through as mentioned above. You just need to use the right syntax as per the manpage (or define them as named colors similar to above). But the "rgb:<red>/<green>/<blue>" (or "#RRGGBB") syntax in particular is defined to use the device space.

None of the device-independent colorspaces documented as standard by XParseColor() are sRGB though, that came later, which is a tad inconvenient in the modern era of wide use of sRGB. OTOH, CIEXYZ is available and there are forward and reverse transforms that can be applied. [2]

HOWEVER... the Xcms [3] scheme predates ICC and isn't really the color calibration system people tend to use nowadays AFAIK, people use xicc [4] which uses the same ICC profiles as found on windows etc., so the chances of a "CIEXYZ:X/Y/Z" color passed to XParseColor() actually winding up mapped to the right CIE XYZ point, well, AFAIUI, that would depend heavily on a user having actually bothered to set up a reasonable Xcms calibration via xcmsdb [5], not just having setup xicc calibration. I suppose some sufficiently advanced tool might exist to extrapolate the Xcms calibration from a now-standard ICC calibration, but that sounds tricky to me (then again, I'm not an expert).

** So if you want NS emacs to treat "#RRGGBB" values like x11 emacs currently does, it does sound to me like the thing to do is colorWithDeviceRed. colorWithCalibratedRed uses the NSCalibratedRGBColorSpace, which AFAICS isn't actually sRGB but isn't the device space either [6][7].

** It would be also presumably be possible to extend ns emacs to internally support some explicitly spelled out device-independent colorspace specification in the color spring like XParseColor() and therefore x11 emacs supports. If doing that, I do suggest using the same syntaxes as x11 for them...

** OTOH it's possible to imagine the emacs project deciding - rather backward incompatibly for x11 users mind you - that, say, "#RRGGBB" syntax color strings in emacs on all platforms are actually to be considered to be in the sRGB colorspace henceforth, like they are officially in html/css.

But #RRGGBB couldn't then be passed straight through to XParseColor() anymore on x11, because #RRGGBB there is defined to be a backward compatibility way of writing colors in the device space also available via "rgb:<red>/<green>/<blue>". They would need to be processed into CIEXYZ and passed to XParseColor() (in the probably vain hope the user has set up Xcms calibration), or (likely yielding better results in the modern era in practice AFAIUI) converted via application of an ICC profile found via xicc into the device space with a library like littlecms [8], which is what GIMP and the like now do.

So a more backward-compat friendly thing to do than using #RRGGBB for srgb, might be to add support within emacs for an "sRGB:<red>/<green>/<blue>" syntax by analogy with the standard XParseColor() ones, and handle it internally (I guess it's unlikely at this stage the xlib maintainers will add such a thing as standard to XParseColor(), but I suppose they might...)

Yeesh,that got long. Hope I wasn't talking nonsense.


[1] http://linux.die.net/man/3/xparsecolor

[2] http://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformation

[3] http://insar.stanford.edu/~lharcke/programming/Xcms/

[4] http://burtonini.com/blog/computers/xicc

[5] http://linux.die.net/man/1/xcmsdb

[6] http://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/DrawColor/Concepts/AboutColorSpaces.html#//apple_ref/doc/uid/20000758-BBCHACHA

[7] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSColorSpace_Class/Reference/Reference.html#//apple_ref/occ/cl/NSColorSpace


[8] http://www.littlecms.com/







reply via email to

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