[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<steve@sanityinc.com> 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/
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/04
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)),
David De La Harpe Golden <=
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/04
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), David De La Harpe Golden, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), David De La Harpe Golden, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), David De La Harpe Golden, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), David De La Harpe Golden, 2011/05/05
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/06
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), David De La Harpe Golden, 2011/05/06
- bug#8402: Acknowledgement (24.0.50; Hex colors are not rendered correctly on OS X (Cocoa)), Steve Purcell, 2011/05/06