[reportlab-users] RGBA Colors

[Kevin D Smith]

After reading all of the discussion about this, it seems like the  
original patch is the least invasive.  It only changes the alpha if it  
is explicitly specified on a color or on the method call, otherwise,  
the alpha just stays where it is.  I can't think of too many ways that  
collisions would occur since I assume that all prepackaged colors from  
ReportLab would continue to only be RGB with no alpha.  The only way  
you would have collisions is if you defined your own colors with  
explicit alpha values *and* used the canvas methods to set an alpha.   
At that point, I would think you'd be an advanced enough user to get  
around the problem (i.e., define the same RGB color w/o an alpha; a  
method could even be added to the color class to create one for you).   
I will say that I am still a fairly new user, so I could still be  
missing some details.

On Nov 26, 2009, at 5:30 AM, Robin Becker wrote:


> 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

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users


Kevin D Smith
Kevin.Smith at sixquickrun.com