[reportlab-users] RGBA Colors

[Robin Becker]

Andy Robinson wrote:

> 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.


unfortunately it's not just a few. We have to define value dictionaries to 
support every value of alpha that gets used and the implication is that we 
change the existing alpha by setting an extg state if the new alpha is 
different. I think that the existing


> 

> 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?


libart does support rgba, but I am not sure how well.


> 

> 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.


This was in fact overprinting (ie anti knockout) and only really applies to PDF 
or real print where the idea of paint mixing makes sense.


> 

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


not really. We have to maintain a global opacity either way. Having the global 
version allows existing subroutines to be rendered with an alpha without any 
extra effort. How the two should combine is a problem and note that this only 
applies to stroking and filling. If my subroutine has an image that won't be 
affected whatever is done. A global alpha could be used to change those as well 
(if we knew how).

Note that this discussion applies equally well to knockout/overprinting ie that 
could be set via the colours and I believe in one renderer we actually did that.
-- 
Robin Becker