Re: Changes 2009-07-15/16 in branch?

[David De La Harpe Golden]

Adrian Robert wrote:

> This sort of thing [in-emacs alphablending] would likely layer 
> over alpha support at the lower level such as that provided by the NS 
port.

Not necessarily at all, all realised colors could be without alpha,
the idea was raised in the context of 256-color terminal users in fact
where alpha computations would be internal to emacs.
(otoh might as well pass it through if it's also there at the OS level, 
 but that would just be a "final alpha" as an output of the blending 
process).

> Does emacs support rgb(r, g, b) or rgb:r/g/b already?

The latter on X11, but N.B. it's really X11 itself supporting it, not 
emacs - i.e. emacs directly asks X11 for colors via the libX11 
XParseColor() API [1] (internally emulated on most other platforms and
text terminals IIRC)

X11 supports  a range of device-dependent and (rather obscure for most 
people) device-independent color specification strings, as well as 
previously mentioned well-known and user-defined names for those colors. 
(None include alpha since alpha isn't historically part of the X color)

Given your interest is alpha and hsv (hsl is neater...), maybe imitating 
the CSS2/3 syntax which includes alpha might be better - and is more 
likely to avoid clashing if X.org extend XParseColor() one fine day. 
CSS syntax could also serve to indicate an sRGB colorspace 
interpretation of rgb triples.
rgb()
rgba()
hsl()
hsla()


[1]
http://linux.die.net/man/3/xparsecolor
e.g.
rgb:<red>/<green>/<blue>
rgbi:<red>/<green>/<blue>
CIEXYZ:<X>/<Y>/<Z>
CIEuvY:<u>/<v>/<Y>
CIExyY:<x>/<y>/<Y>
CIELab:<L>/<a>/<b>
CIELuv:<L>/<u>/<v>
TekHVC:<H>/<V>/<C>