[reportlab-users] How to save drawings with transparent background as PNG? (Was Re: reportlab-users Digest, Vol 102, Issue 11)

Robin Becker robin at reportlab.com
Tue Aug 28 06:52:05 EDT 2012


..........

>

> Sorry, if my message caused any confusion, but in fact, yes, in my

> first one I referred to generating PNG files with a transparent back-

> ground from RL drawings (reportlab.graphics.shapes.Drawing).

Dinu,

the _renderPM graphics state supports only 3 planes ie RGB. To properly support
transparency we probably need 4. PNG uses RGBA so I presume that would be a
requirement. Some of the internal code in _renderPM.c allows for a buffer with 4
planes, but there are a lot of places where we make the 3 plane assumption.

We are supporting Alpha stroke and fill, but that's over RGB and not over RGBA.

There is some support in renderPM.py for the old style GIF/TIFF transparency ie
you nominate a single rgb triplet as the transparent colour. That could be
pursued with PNG, but it's not full alpha anyhow.



>

> And in the second I referred to overlaying one transparent PNG image

> of the class reportlab.graphics.shapes.Image over another (not ne-

> cessarily transparent image of the same class) inside a drawing and

> saving this to a PNG file respecting the transparency effect.

>

Our back end doesn't support composition for proper RGBA so I think you're also
stuck here.
........

> BTW, it would be very nice to allow reportlab.graphics.shapes.Image

> to read a file also from a StringIO object and not only from a real

> file object in the filesystem.

........
You can put a PIL image in and it gets converted to RGB to match our existing
internal canvas. I suppose we could add the option to use a .read method as well.



I think libart_lgpl contains all of the required primitives for what you want,
but making this all work properly would be a bit of an effort.

I presume the steps would be as follows

1) The drawing would need to keep track of whether Alpha<1 values have been
used. Presumably we need alpha if we demand it or any pixel is not fully opaque.
That's quite a hard test. Probably we should just make this explicit.

2) If we need 4 planes then the gstate would need to be set up as 4 planes
rather than 3.

3) All of the primitive drawing ops would need to check not only the incoming
alpha, but also the background alpha and select the appropriate rendering
operation to do the composition.
--
Robin Becker


More information about the reportlab-users mailing list