[reportlab-users] RGBA Colors

[Andy Robinson]

2009/11/26 Robin Becker <robin at reportlab.com>:

> My preference for an interaction between the canvas and colour alphas would

> be something like a set of rules for the colour behaviours


I think we should step back a bit.   First of all, is anyone on this
list apart from Kevin using opacity?

I know we try very hard not to break code, but it seems cleaner and
more useful to me if RGBColor instances just grow a fourth attribute
with a default of 1, and we deprecate the opacity methods on the
canvas.  And then, every time we set a colour, we set the alpha too.
You could then make a shape or flowable whose colour was 'red with 50%
opacity'.

Every set-colour operation will need a few extra bytes of
(uncompressed) markup and a tiny bit of processing.  However, we have
to ask what proportion of real-world documents switch colours hundreds
of times.

We would also have to look at renderPM and the bitmap output, as
ideally any kind of bitmap preview (common on the web) should be
fairly faithful.   Robin, does renderPM/libart have the capability in
principle to show transparent output?

We have done some work recently in the print world where there are
other techniques for achieving transparency or blends, and we did that
by adding a 'density' parameter to the relevant colour objects.

Robin, would this be cleaner internally than supporting 'both ways'?

Kevin, would this fit better with what you want to do?

Everyone, is this a more useful model for transparency?



- Andy