[reportlab-users] Memory consumption of a "simple" document s eems excessive

[Hancock, David (DHANCOCK)]

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.

I just saw the message about using the bug-tracker on Sourceforge.  Did this
already get in or shall I enter it?

Cheers!
--
David Hancock | dhancock@arinc.com | 410-266-4384

-----Original Message-----
From: Andy Robinson [mailto:andy@reportlab.com] 
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

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.

    img = Image('fullsize.gif', width=1728/4, height=1108/4)
    img.hAlign = 'CENTER'

    Story.append(img)

    Story.append(Spacer(1, 0.1*inch))
    doc.build(Story, onFirstPage=myPage)

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.

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

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.


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.

Best Regards,

Andy Robinson

> -----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