[Top][All Lists]

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

Re: sRGB color support in NS port [PATCH]

From: David De La Harpe Golden
Subject: Re: sRGB color support in NS port [PATCH]
Date: Sat, 21 Dec 2013 20:26:58 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 21/12/13 17:37, Steve Purcell wrote:

On Windows, the RGB colour literals will be assumed to be coordinates within 
its default sRGB space.
> On OS X, emacs will claim that they are in the vague “calibrated” space, which is not sRGB, so > they will automatically look different between the two platforms. This seems like a shortcoming to > me, and it’s not clear to me that making the color space a user preference is the correct fix, at
> least if the default is the calibrated space.

But maybe I've missed something and/or my logical understanding of the
> situation is flawed, and I’d be happy to find out how. :-)

Well, doesn't change things much, but I'm not sure "[Apple] Generic RGB" is as vague as you think. No, it's not the same as either historical "Apple RGB" or of course sRGB, but doesn't quite look to me like it's just some "a generic RGB color space" in the sense the wikipedia absolute colorspaces article you previously linked meant. [1][2]

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. sRGB is obviously fine for ordinary text-editing and coding, you don't need wide gamut for a few different syntax highlights, and it's actively beneficial for the webdev guys. And cross-platform consistency of emacs color themes might be something a lot of users want.

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])

...that's a reasonable enough project decision if you ask me. Not sure I'd bother even including an option to switch the default color space for such unqualified triples to anything else (just maybe note that at some future date a larger component value range may become valid, for scRGB).

But do bear in mind X11 has history here. The full X11 color specification string syntax that is fundamentally where emacs gets its notions of how to interpret color specifications has long included support for explicitly device-independent colors with a color space qualification prefix like e.g. "CIEXYZ:x/y/z". Though no-one ever added support for "srgb:r/g/b" to date which is a shame, and it may be difficult to find X people who care to do so now, with so many treating X as legacy and looking to Wayland (and I imagine that'll almost certainly default to sRGB, though haven't checked).

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). So if emacs DOES decide the above, X11 color handling code will need work: X11 emacs wouldn't be able to just hand off all color strings to X11 for resolution any more, it would have to treat color-space-unqualified triples (and perhaps named colors) differently to X11 itself.

(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)

[1] https://developer.apple.com/library/mac/qa/qa1430/_index.html
[2] https://github.com/gnachman/iTerm2/pull/149


reply via email to

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