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

[reportlab-users@reportlab.com]

Robin Becker wrote:
>In article <OF81468B04.F56B895D-ONC1256E15.00403021@ubitrade.com>,
>amaury.forgeotdarc@ubitrade.com writes
>>Robin Becker wrote:
>>> ..... yes at some point in the past we broke our own code. Even if the
>>> old mechanism were in place I think there is still an issue about
>>> splitting as _postponed is a hack that's set by doctemplate and nobody
>>> requires the split to preserve it.
>>
>>But the split must not preserve it!
>>If I understand the code correctly, the split replaces the big flowable
>>by a list of (smaller) flowables.
>>The _postponed must be reset to 0.
>>
>>There is still a risk when split() systematically returns a list
>>where the first argument is as high as the original flowable.
>>But there is no page break there.
>>
>>--
>>Amaury Forgeot d'Arc
>.... that's what I meant. Since flowables don't know/care about
>_postponed they can't be clever about setting it to zero or preserving
>it if they make no progress. If one of the split returns is as large as
>the original then it should logically have _postponed = 1
>--
>Robin Becker


I was wrong when I said there is a risk when the split function
makes no progress.

If the first item of the split cannot fit in the
available space, then a LayoutError is raised
(line 538, short after
     if self.frame.add(S[0], ...
)

The first item after a split *must* fit in the available space.
(This should be in the docs, I did not check)
And there is no risk of infinite loop there.

--
Amaury Forgeot d'Arc