[reportlab-users] Re: Infinite loop detection

[Henning von Bargen]

> In article <PGECLPOBGNBNKHNAGIJHCEMMIDAA.andy@reportlab.com>, Andy
> Robinson <andy@reportlab.com> writes
> ......
> 
> There are difficulties. At one point I thought it would be sufficient to
> use introspection to determine where the flowable was generated (which
> could be done using stack frames etc at flowable instantiation), but
> most flowables are generated by some more or less anonymous process eg
> database lookup and similar so some part of the identity should be based
> on the contents.
> 
> >Any thoughts on this?
> >

The difficulties already start at determining an infinite loop.

An ininite loop happens occurs iff the story (=list of flowables)
doesn't get any "shorter" even after trying to begin a new page
for N times (in practice, N=10).

The problem is to decide what "shorter" actually means.
An example:
Consider a table with repeatRows=1
and the first row is so long that the second row will never fit
(this may actually happen when working with DB data).
The table splits into two new tables,
the first one containing only the first row,
and the second one still containing all rows.
This leads to an infinite loop.

The same could possibly happen if you want to keep
header lines and paragraph text together (if the header line is too long).

I think it is necessary to decide if content data has been "consumed"
on the page. One would need a flag "dataConsumed" that is
set to false for every new page.
Then, when a flowable is formatted on the page,
the flag can be set to true.
An exception is for repeating rows in a table
and perhaps similar objects (which?):
These must not set the dataConsumed flag,
because they will be repeated on the following pages
and thus they don't consume data.

The implementation could be quite tricky, though.

Henning