[reportlab-users] RE: Infinite Loops
Henning von Bargen
reportlab-users@reportlab.com
Thu, 8 Jan 2004 09:44:34 +0100
I have experienced the infinite loop problem
with tables that don't fit on the page even with splitting
(if the table is too wide or a single row too long).
I did not test your code (my application counts pages and stops after =
500
pages).
Infinite loop detection makes sense (works in Oracle Reports, too).
But as David Hancock pointed out, it would help a lot if one knew
what flowable object caused the trouble.
However, this might not be possible.
Another good solution would be to just stop building the PDF document
and instead of just raising an exception=20
reportlab should still output the resulting PDF together with an error
message or exception
so that the user can see how far the building process got.
Henning
> -----Urspr=FCngliche Nachricht-----
> Von: reportlab-users-request@reportlab.com
[SMTP:reportlab-users-request@reportlab.com]
> Gesendet am: Donnerstag, 8. Januar 2004 04:42
> An: reportlab-users@reportlab.com
> Betreff: reportlab-users digest, Vol 2 #6 - 14 msgs
>=20
> Send reportlab-users mailing list submissions to
> reportlab-users@reportlab.com
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> http://two.pairlist.net/mailman/listinfo/reportlab-users
> or, via email, send a message with subject or body 'help' to
> reportlab-users-request@reportlab.com
>=20
> You can reach the person managing the list at
> reportlab-users-admin@reportlab.com
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of reportlab-users digest..."
>=20
>=20
> Today's Topics:
>=20
> 1. Re: Table and document widths (Will Newton)
> 2. RE: Memory consumption of a "simple" document s
> eems excessive (Hancock, David (DHANCOCK))
> 3. RE: Memory consumption of a "simple" document seems excessive =
(Andy
Robinson)
> 4. RE: Memory consumption of a "simple" document s
> eems excessive (Hancock, David (DHANCOCK))
> 5. RE: Memory consumption of a "simple" document seems excessive =
(Andy
Robinson)
> 6. Re: Table and document widths (Robin Becker)
> 7. RE: Memory consumption of a "simple" document seems excessive =
(Andy
Robinson)
> 8. RE: Memory consumption of a "simple" document seems excessive =
(Ian
Sparks)
> 9. RE: Memory consumption of a "simple" document seems excessive =
(Andy
Robinson)
> 10. Release schedule and bug tracking (Andy Robinson)
> 11. RE: Memory consumption of a "simple" document s
> eems excessive (Hancock, David (DHANCOCK))
>=20
> --__--__--
>=20
> Message: 1
> Date: Wed, 7 Jan 2004 08:59:34 +0000
> To: reportlab-users@reportlab.com
> Subject: Re: [reportlab-users] Table and document widths
> From: Will Newton <will@gbdirect.co.uk>
> Reply-To: reportlab-users@reportlab.com
>=20
> On Tue, Jan 06, 2004 at 05:32:14PM +0000, Robin Becker wrote:
>=20
> > well you can assume that the doc width is 12 points too large if =
you
> > want to do percentages. Unfortunately we don't yet allow setting =
the
> > widths as percentages so you'd have to do this yourself.
>=20
> Is there any way to get the current frame so I can do frame.width
> instead? It would seem less fragile. You say SimpleDocTemplate =
doesn't
> create the frames until build time, but I'm not sure how to get the
> current frame (or PageTemplate) with
> BaseDocTemplate either.=20
>=20
> --__--__--
>=20
> Message: 2
> From: "Hancock, David (DHANCOCK)" <DHANCOCK@arinc.com>
> To: "'reportlab-users@reportlab.com'" <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document s
> eems excessive
> Date: Wed, 7 Jan 2004 06:35:49 -0500=20
> Reply-To: reportlab-users@reportlab.com
>=20
> I've tried the page with and without height and width parameters that
force
> it to the page size, and the runaway memory is a problem both ways. I =
have
> been able to make the PDF if I don't try to switch the page to =
landscape
> orientation, but in landscape, I start to run out of memory when I =
try to
> expand the image to fit the page better.
>=20
> Thanks for the idea--I'll try various sizes in portrait mode and see =
if
that
> sheds some light.
>=20
> If anybody has a nice magic bullet for me, that would be great, too.
>=20
> Cheers!
> --
> David Hancock | dhancock@arinc.com | 410-266-4384
>=20
>=20
> -----Original Message-----
> From: Jerome Alet [mailto:alet@librelogiciel.com]=20
> Sent: Wednesday, January 07, 2004 1:28 AM
> To: reportlab-users@reportlab.com
> Subject: Re: [reportlab-users] Memory consumption of a "simple" =
document
> seems excessive
>=20
>=20
> Hi,
>=20
> On Tue, Jan 06, 2004 at 06:24:19PM -0500, Hancock, David (DHANCOCK) =
wrote:
> > I've looked at the FAQ and Googled for "reportlab memory =
consumption"
but
> > couldn't find anything relevant.
>=20
> That's probably because your image is too large to fit on a page.
>=20
> bye
>=20
> Jerome Alet
> --=20
> "A non-free program is a predatory social system that keeps people=20
> in a state of domination and division, and uses the spoils to=20
> dominate more." - RMS
> _______________________________________________
> reportlab-users mailing list
> reportlab-users@reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>=20
> --__--__--
>=20
> Message: 3
> From: "Andy Robinson" <andy@reportlab.com>
> To: <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
seems excessive
> Date: Wed, 7 Jan 2004 14:12:56 -0000
> Reply-To: reportlab-users@reportlab.com
>=20
> > If anybody has a nice magic bullet for me, that would be great, =
too.
>=20
> We don't get problems like this and I routinely make 'albums'
> out of big JPEGs. How big is the underlying GIF file? If less=20
> than a few hundred k, please email it to me and I'll try it.
>=20
> - Andy
>=20
>=20
> --__--__--
>=20
> Message: 4
> From: "Hancock, David (DHANCOCK)" <DHANCOCK@arinc.com>
> To: "'reportlab-users@reportlab.com'" <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document s
> eems excessive
> Date: Wed, 7 Jan 2004 09:21:12 -0500=20
> Reply-To: reportlab-users@reportlab.com
>=20
> I'll send Andy the .gif and .py files. The GIF is under 70K (very =
sparse
> black and white image--a US weather synopsis). If the list is =
interested,
> I'll post here also; let me know.
>=20
> Cheers!
> --
> David Hancock | dhancock@arinc.com | 410-266-4384
>=20
>=20
> -----Original Message-----
> From: Andy Robinson [mailto:andy@reportlab.com]=20
> Sent: Wednesday, January 07, 2004 9:13 AM
> To: reportlab-users@reportlab.com
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> seems excessive
>=20
>=20
> > If anybody has a nice magic bullet for me, that would be great, =
too.
>=20
> We don't get problems like this and I routinely make 'albums'
> out of big JPEGs. How big is the underlying GIF file? If less=20
> than a few hundred k, please email it to me and I'll try it.
>=20
> - Andy
>=20
> _______________________________________________
> reportlab-users mailing list
> reportlab-users@reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>=20
> --__--__--
>=20
> Message: 5
> From: "Andy Robinson" <andy@reportlab.com>
> To: <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
seems excessive
> Date: Wed, 7 Jan 2004 15:21:23 -0000
> Reply-To: reportlab-users@reportlab.com
>=20
> Looks like we have a bug somewhere when we try to size
> images. The following works fine so there is nothing
> wrong with your GIF or our streaming to disk...
>=20
> import reportlab.pdfgen.canvas
> c =3D reportlab.pdfgen.canvas.Canvas('fullsize.pdf')
> c.drawImage('fullsize.gif',0,0,800,500)
> c.save()
> print 'done'
> I'll let you know as soon as we have a fix.
>=20
> - Andy
>=20
>=20
>=20
> > -----Original Message-----
> > From: reportlab-users-admin@reportlab.com
> > [mailto:reportlab-users-admin@reportlab.com]On Behalf Of Hancock, =
David
> > (DHANCOCK)
> > Sent: 07 January 2004 14:21
> > To: 'reportlab-users@reportlab.com'
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > I'll send Andy the .gif and .py files. The GIF is under 70K (very =
sparse
> > black and white image--a US weather synopsis). If the list is
interested,
> > I'll post here also; let me know.
> >
> > Cheers!
> > --
> > David Hancock | dhancock@arinc.com | 410-266-4384
> >
> >
> > -----Original Message-----
> > From: Andy Robinson [mailto:andy@reportlab.com]
> > Sent: Wednesday, January 07, 2004 9:13 AM
> > To: reportlab-users@reportlab.com
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > > If anybody has a nice magic bullet for me, that would be great, =
too.
> >
> > We don't get problems like this and I routinely make 'albums'
> > out of big JPEGs. How big is the underlying GIF file? If less
> > than a few hundred k, please email it to me and I'll try it.
> >
> > - Andy
> >
> > _______________________________________________
> > reportlab-users mailing list
> > reportlab-users@reportlab.com
> > http://two.pairlist.net/mailman/listinfo/reportlab-users
> > _______________________________________________
> > reportlab-users mailing list
> > reportlab-users@reportlab.com
> > http://two.pairlist.net/mailman/listinfo/reportlab-users
> >
>=20
>=20
> --__--__--
>=20
> Message: 6
> Date: Wed, 7 Jan 2004 21:07:07 +0000
> To: reportlab-users@reportlab.com
> From: Robin Becker <robin@reportlab.com>
> Subject: Re: [reportlab-users] Table and document widths
> Reply-To: reportlab-users@reportlab.com
>=20
> In article <20040107085934.GA23227@gbdirect.co.uk>, Will Newton
> <will@gbdirect.co.uk> writes
> >On Tue, Jan 06, 2004 at 05:32:14PM +0000, Robin Becker wrote:
> >
> >> well you can assume that the doc width is 12 points too large if =
you
> >> want to do percentages. Unfortunately we don't yet allow setting =
the
> >> widths as percentages so you'd have to do this yourself.
> >
> >Is there any way to get the current frame so I can do frame.width
> >instead? It would seem less fragile. You say SimpleDocTemplate =
doesn't
> >create the frames until build time, but I'm not sure how to get the
> >current frame (or PageTemplate) with
> >BaseDocTemplate either.=20
>=20
> The frame sizes and positions are a user choice. The frames in a page
> template are also a user choice. So you define your templates by =
adding
> specified frames to them. A typical sequence might be
>=20
> doc =3D BaseDocTemplate('dingo.pdf')
> frame1 =3D Frame(self.leftMargin, self.bottomMargin, self.width,
> self.height, id=3D'normal')
> doc.addPageTemplates([PageTemplate(id=3D'First',frames=3Dframe1,
> pagesize=3Ddoc.pagesize)])
>=20
> Here frame1 has a specified width and height which you set up front.
>=20
> If you don't know in advance which frame you'll be using then there =
are
> more complex ways to do things. A relatively simple way to do things
> would be to create an intelligent table class.
>=20
> from reportlab.platypus import Table
> class SpecialTable(Table):
> def wrap(self,aW,aH):
> '''when called aW is the full width of the container'''
> n =3D len(self._argW)
> # equal column widths
> self._argW =3D self._colWidths =3D [float(aW)/n]*n
> # now really wrap
> Table.wrap(self,aW,aH)
>=20
> Does this help?
> --=20
> Robin Becker
>=20
> --__--__--
>=20
> Message: 7
> From: "Andy Robinson" <andy@reportlab.com>
> To: <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
seems excessive
> Date: Wed, 7 Jan 2004 22:59:05 -0000
> Reply-To: reportlab-users@reportlab.com
>=20
>=20
> Here's a workaround. You must explicitly specify a point size
> which fits within the frame of your document. Remember that
> frames have 6 points padding all round. I divided the
> pixel dimensions by 4. If I change the line creating
> the image flowable so it fits, the script runs in a fraction
> of a second and makes a 150k PDF as expected.
>=20
> img =3D Image('fullsize.gif', width=3D1728/4, height=3D1108/4)
> img.hAlign =3D 'CENTER'
>=20
> Story.append(img)
>=20
> Story.append(Spacer(1, 0.1*inch))
> doc.build(Story, onFirstPage=3DmyPage)
>=20
> This has exposed a serious bug. The problem is that the flowable
> won't fit on the page, and it won't fit on the next page either.
> In this situation we should be raising an exception but it seems
> there is an infinite loop. I think we lost a piece of code
> somewhere.
>=20
> I just checked in a candidate fix for this but would welcome
> comments. The idea is to track likely "infinite loops" and
> raise an exception. BaseDocTemplate gets 3 new sttributes:
> _curPageFlowableCount
> _emptyPagesAllowed (default 3)
> _emptyPages
>=20
> Any time a flowable is added to a frame, _curPageFlowablCount
> is incremented. It gets reset when a page starts.
> Any time a page ends with no content added, it increments
> _emptyPages. If there is content, _emptyPages is set back
> to zero.
> If _emptyPages reaches emptyPagesAllowed, it throws an exception.
>=20
>=20
> So, after 3 empty pages it will raise an exception. We used to
> do 1 page, but it's possible to imagine complex newsletter
> layouts where page X doesn't have room for a document but page
> X+1 does, so I added a little leniency.
>=20
> Best Regards,
>=20
> Andy Robinson
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: reportlab-users-admin@reportlab.com
> > [mailto:reportlab-users-admin@reportlab.com]On Behalf Of Hancock, =
David
> > (DHANCOCK)
> > Sent: 07 January 2004 14:21
> > To: 'reportlab-users@reportlab.com'
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > I'll send Andy the .gif and .py files. The GIF is under 70K (very =
sparse
> > black and white image--a US weather synopsis). If the list is
interested,
> > I'll post here also; let me know.
> >
> > Cheers!
> > --
> > David Hancock | dhancock@arinc.com | 410-266-4384
> >
> >
> > -----Original Message-----
> > From: Andy Robinson [mailto:andy@reportlab.com]
> > Sent: Wednesday, January 07, 2004 9:13 AM
> > To: reportlab-users@reportlab.com
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > > If anybody has a nice magic bullet for me, that would be great, =
too.
> >
> > We don't get problems like this and I routinely make 'albums'
> > out of big JPEGs. How big is the underlying GIF file? If less
> > than a few hundred k, please email it to me and I'll try it.
> >
> > - Andy
> >
> > _______________________________________________
> > reportlab-users mailing list
> > reportlab-users@reportlab.com
> > http://two.pairlist.net/mailman/listinfo/reportlab-users
> > _______________________________________________
> > reportlab-users mailing list
> > reportlab-users@reportlab.com
> > http://two.pairlist.net/mailman/listinfo/reportlab-users
> >
>=20
>=20
> --__--__--
>=20
> Message: 8
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
seems excessive
> Date: Wed, 7 Jan 2004 18:03:53 -0500
> From: "Ian Sparks" <Ian.Sparks@etrials.com>
> To: <reportlab-users@reportlab.com>
> Reply-To: reportlab-users@reportlab.com
>=20
> Andy Robinson wrote:
> >>
> This has exposed a serious bug. The problem is that the flowable
> won't fit on the page, and it won't fit on the next page either.
> In this situation we should be raising an exception but it seems
> there is an infinite loop. I think we lost a piece of code
> somewhere.
> <<
>=20
> Is this at all related to the TableOfDoom problem? That too seems to =
go =3D
> into an infinite-loop when a table won't fit a page.
>=20
>=20
>=20
>=20
> --__--__--
>=20
> Message: 9
> From: "Andy Robinson" <andy@reportlab.com>
> To: <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
seems excessive
> Date: Wed, 7 Jan 2004 23:32:54 -0000
> Reply-To: reportlab-users@reportlab.com
>=20
> > Is this at all related to the TableOfDoom problem? That too=20
> > seems to go into an infinite-loop when a table won't fit a page.
>=20
> Could well be the same. It would be great if anyone experiencing
> such problems could do some retesting on the daily or CVS snapshots.
>=20
> It is not the same as the non-linear-performance-of-large-tables
> which Henning has offered a fix for and which we will work
> in next.
>=20
> - Andy
>=20
> --__--__--
>=20
> Message: 10
> From: "Andy Robinson" <andy@reportlab.com>
> To: "Reportlab-Users@Reportlab. Com" <reportlab-users@reportlab.com>
> Date: Wed, 7 Jan 2004 23:49:00 -0000
> Subject: [reportlab-users] Release schedule and bug tracking
> Reply-To: reportlab-users@reportlab.com
>=20
> Happy New Year to all our users. =20
>=20
> Here are some notices about upcoming changes.
>=20
> Impending Release
> -----------------
>=20
> After some debate, we've decided to concentrate on
> getting a really stable bug fix release out in the next
> couple of weeks. Key goals are
> - complains loudly if you run it on Python 1.5.2 :-)
> - zero 'future warnings' under Python 2.3
> - 100% certified to run under Jython, with _rl_accel.java
> - renderPM now supports TrueType font rendering
> - ensure all demos and tools are tested on Windows,
> [?|??]n?x and Mac
> - the recent infinite loops, layout problems and other
> 'bugs which matter' all closed off
> - quite a few new features in Pythonpoint
> =20
> Sadly it is not realistic to do full support for right-to-left
> or Asian languages; those issues are big.
>=20
> We'll make sure daily snaphots are up so that people can
> help us test, and get a good stable baseline out.
>=20
> This will quite possibly have some "impact" on existing
> scripts as we want to tighten up some lax usages that
> have bitten us before. We'll aim to have these documented
> prior to the release with workarounds.
>=20
>=20
> 2. Tracking Bugs
> -----------------
> I am also making some policy changes. From now on we will use=20
> the SourceForge bug tracker, patch manager and feature requests. =20
> If you have outstanding bugs or patches, play safe by reminding us on =
> the list and post them on SourceForge:
> http://sourceforge.net/projects/reportlab
>=20
>=20
> This has NOT been driven by continual nagging from
> you-know-who, but rather from reaching a level of staffing=20
> where I am fairly confident we can make time before
> each release to properly investigate bug reports.
> We were so understaffed and overworked last year
> that we couldn't promise to investigate bugs that were not
> biting us, but it's getting easier as we grow. =20
>=20
>=20
> 3. Use of Sourceforge and collaboration tools
> ----------------------------------------------
> We missed our deadlines for getting a collaboration
> site up, but we did manage our server upgrades over Christmas
> and New Year. =20
>=20
> After a bit more thought I would like to try and use
> Sourceforge better before we work on Wikis or CMSes.
> We'll try to set up the access controls so we can
> grant wide checkin rights to a sandbox/contrib area.
>=20
> If anyone out there would be willing to share the work
> of patch screening, making releases, improving documentation
> or any of the other activities crucial to good open
> source packages, let me know and we'll consider granting=20
> commit rights.
>=20
> I'm still happy to set up an experimental Plone server
> if people want to, but I'd like to see some people
> ask for this on the list, so we don't do a lot of
> work that will only get 1-2 users.
>=20
> Best Regards,
>=20
>=20
>=20
>=20
>=20
> Andy Robinson
> CEO/Chief Architect
> ReportLab Europe Ltd.
> mobile +44-7976-355742
> office +44-20-8544-8049
> =20
>=20
> --__--__--
>=20
> Message: 11
> From: "Hancock, David (DHANCOCK)" <DHANCOCK@arinc.com>
> To: "'reportlab-users@reportlab.com'" <reportlab-users@reportlab.com>
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document s
> eems excessive
> Date: Wed, 7 Jan 2004 22:38:28 -0500=20
> Reply-To: reportlab-users@reportlab.com
>=20
> This is great! I appreciate both the workaround and the attention to =
the
> issue. My only hope about the fix is that the exception raised can =
give a
> clue about what went wrong and how to fix it. I don't know if =
"infinite
> loop" would be enough information for me to have figured this out on =
my
own.
>=20
> I just saw the message about using the bug-tracker on Sourceforge. =
Did
this
> already get in or shall I enter it?
>=20
> Cheers!
> --
> David Hancock | dhancock@arinc.com | 410-266-4384
>=20
> -----Original Message-----
> From: Andy Robinson [mailto:andy@reportlab.com]=20
> Sent: Wednesday, January 07, 2004 5:59 PM
> To: reportlab-users@reportlab.com
> Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> seems excessive
>=20
> Here's a workaround. You must explicitly specify a point size
> which fits within the frame of your document. Remember that
> frames have 6 points padding all round. I divided the
> pixel dimensions by 4. If I change the line creating
> the image flowable so it fits, the script runs in a fraction
> of a second and makes a 150k PDF as expected.
>=20
> img =3D Image('fullsize.gif', width=3D1728/4, height=3D1108/4)
> img.hAlign =3D 'CENTER'
>=20
> Story.append(img)
>=20
> Story.append(Spacer(1, 0.1*inch))
> doc.build(Story, onFirstPage=3DmyPage)
>=20
> This has exposed a serious bug. The problem is that the flowable
> won't fit on the page, and it won't fit on the next page either.
> In this situation we should be raising an exception but it seems
> there is an infinite loop. I think we lost a piece of code
> somewhere.
>=20
> I just checked in a candidate fix for this but would welcome
> comments. The idea is to track likely "infinite loops" and
> raise an exception. BaseDocTemplate gets 3 new sttributes:
> _curPageFlowableCount
> _emptyPagesAllowed (default 3)
> _emptyPages
>=20
> Any time a flowable is added to a frame, _curPageFlowablCount
> is incremented. It gets reset when a page starts.
> Any time a page ends with no content added, it increments
> _emptyPages. If there is content, _emptyPages is set back
> to zero.
> If _emptyPages reaches emptyPagesAllowed, it throws an exception.
>=20
>=20
> So, after 3 empty pages it will raise an exception. We used to
> do 1 page, but it's possible to imagine complex newsletter
> layouts where page X doesn't have room for a document but page
> X+1 does, so I added a little leniency.
>=20
> Best Regards,
>=20
> Andy Robinson
>=20
> > -----Original Message-----
> > From: reportlab-users-admin@reportlab.com
> > [mailto:reportlab-users-admin@reportlab.com]On Behalf Of Hancock, =
David
> > (DHANCOCK)
> > Sent: 07 January 2004 14:21
> > To: 'reportlab-users@reportlab.com'
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > I'll send Andy the .gif and .py files. The GIF is under 70K (very =
sparse
> > black and white image--a US weather synopsis). If the list is
interested,
> > I'll post here also; let me know.
> >
> > Cheers!
> > --
> > David Hancock | dhancock@arinc.com | 410-266-4384
> >
> >
> > -----Original Message-----
> > From: Andy Robinson [mailto:andy@reportlab.com]
> > Sent: Wednesday, January 07, 2004 9:13 AM
> > To: reportlab-users@reportlab.com
> > Subject: RE: [reportlab-users] Memory consumption of a "simple" =
document
> > seems excessive
> >
> >
> > > If anybody has a nice magic bullet for me, that would be great, =
too.
> >
> > We don't get problems like this and I routinely make 'albums'
> > out of big JPEGs. How big is the underlying GIF file? If less
> > than a few hundred k, please email it to me and I'll try it.
> >
> > - Andy
>=20
>=20
> --__--__--
>=20
> _______________________________________________
> reportlab-users mailing list
> reportlab-users@reportlab.com
> http://two.pairlist.net/mailman/listinfo/reportlab-users
>=20
>=20
> End of reportlab-users Digest