[reportlab-users] RGBA Colors

[Kevin D Smith]

On Nov 24, 2009, at 10:53 AM, Robin Becker wrote:

> Kevin D Smith wrote:

>> A little while ago I asked if there was a way to get RGBA colors  

>> (like in CSS3) where the A component is an alpha value to set  

>> transparency.  While doing some searching last night, I realized  

>> that the svn version of ReportLab already has alpha support;  

>> however, it didn't go quite as far as I had hoped.  Methods were  

>> added to the canvas to set the fill and stroke opacity, which is  

>> nice, but if you are using Platypus, you don't have access to them.

>> I messed around with the code a bit in textobject.py and colors.py  

>> to add alpha arguments to all of the color methods as well as an  

>> alpha component to rgb and cmyk colors.  With the attached patch,  

>> you can specify colors with an alpha value that can be used in  

>> Platypus or anywhere else colors are used.  I would like this patch  

>> to be considered for official use so that I don't have to remember  

>> to add this support for my projects.  Does anyone know what that  

>> would take?

> .........

>

> This looks like a nice patch, but there might be hidden problems.  

> The opacity patch was contributed and one of the approaches  

> considered was that opacity should go into the colour objects.  

> However, since opacity is actually stored on the canvas there are  

> problems related to using a mixture of colours containing alpha and  

> non-alpha colours.

>

> In the colour+a model setting a colour with a in [0,1] means an  

> action is carried out on the canvas.

>

> So

>

> setFill(red+alpha=0.5) ==> canvas alpha = 0.5

>

> follow that by

>

> setFill(black+alpha=None)   canvas alpha remains 0.5

>

> which I would argue is unexpected. Forgive me if your patch doesn't  

> exactly follow this model, but that's what my quick scan seems to  

> imply.

>

> We seem to need to get the incoming colour+alpha=None to restore the  

> appropriate alpha value. The problem then is what that value should  

> be; who owns the alpha value?

>

> I'm not against this idea, I did already consider such a mechanism.  

> Perhaps others would like to comment.

>

> One other point is that it is very easy to make a flowable that  

> allows platypus to mess with canvas properties.

> -- 

> Robin Becker



I think I have a solution that will work for manually setting of an  
alpha as well as supporting alpha in colors.  An alpha set on the  
canvas itself is intended to make everything from that point on semi- 
transparent.  Setting an alpha on a color means to only make that  
color semi-transparent.  It seems to me that if you stored any alpha  
values set by setStrokeAlpha or setFillAlpha in an instance variable  
on the canvas, those could be considered the global alpha for the  
canvas.  If a color was specified with an alpha, the alpha of that  
color would be multiplied by the current canvas alpha setting, but  
would not be stored in the alpha instance variables.

This technique would allow any manual settings of alpha to persist  
while colors could also control the alpha level.  For users who want  
the manual control, everything will work the way they want.  For those  
who use the higher-level interfaces such as Platypus, there would be  
no manual alpha manipulations, so it would work correctly for them as  
well.  When both are used, the effect simply combines.

The only thing I'm sure about is the architectural aspect of it.  Can  
colors and their alphas be popped off and have the canvas alpha value  
reset to the previous value (held in the instance variables), or is  
that just not possible?  If it is possible, I think this technique  
would work.

Kevin D Smith
Kevin.Smith at sixquickrun.com