[reportlab-users] RGBA Colors

[Kevin D Smith]

On Nov 24, 2009, at 11:17 AM, Kevin D Smith wrote:

> 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 see your point about alpha not being reset.  I was using the None  

> value in the methods and the colors themselves so that they wouldn't  

> force a PDF document to be versioned as 1.4 unless alpha was  

> explicitly used.  If I didn't care about that fact, I would have set  

> alpha to 1 in all of those places.  But it is a bit problematic  

> making it both work properly and be backwards compatible.

>

> As far as writing flowables to use the canvas properties, at the  

> moment, I use very basic components of platypus like paragraphs and  

> tables.  I would prefer not to have to write customized ones just to  

> get alpha values in the colors.

>

> Kevin D Smith

> Kevin.Smith at sixquickrun.com



After thinking about it for a few more minutes, one possible solution  
would be to set a variable that indicates whether or not alphas have  
been used in the document.  If they have, then the default alpha value  
in colors and methods should be treated as 1.  If alphas haven't been  
used, then the default value is None.  I'm not sure architecturally  
where a flag light that might be able to exist since this is my first  
foray into the ReportLab code.

Kevin D Smith
Kevin.Smith at sixquickrun.com