[reportlab-users] RGBA Colors

[Kevin D Smith]

I think I tripped across an issue with using alphas.  I was drawing a box with borders (each component done with rect(...)).  The background had an alpha set using an RGBA color, but the borders had an alpha value of 1.  For whatever reason, the background and the top, right, and bottom borders came out with the alpha.  The left border came out completely opaque.  I'm not sure why just the left border came out opaque.  I drew the objects in the order: background, left, top, right, bottom.  In order to get the behavior I wanted, I had to save the state before drawing the background, then restore it afterward.  This seems to be an issue with the alpha implementation even without the patch since I was setting the alpha explicitly for each of the components and it still happened.

I've attached the test PDF that I created.  The code is part of a much larger program so it would be tricky to separate it out, but I could probably work up a test case if needed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pdf
Type: application/pdf
Size: 31443 bytes
Desc: not available
Url : <http://two.pairlist.net/pipermail/reportlab-users/attachments/20091201/49c22646/attachment-0001.pdf>
-------------- next part --------------

On Nov 26, 2009, at 9:20 AM, Kevin D Smith wrote:


> 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

> 

> 

> 

> _______________________________________________

> 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