Paul Tremblay wrote:
So forward references would mean memory cannot be released?
Correct.
The machinery in FOP 0.20.5 roughly works a follows:
Read the layout master set. Fortunately, it must be the
first element in fo:root.
loop until fo:root closes
Build an internal representation of a FO tree for a
page sequence.
Loop until all FOs are laid out
Create an area tree for a page and add it to the page queue.
loop until page queue is empty
if queue head can be rendered (no unresolved references)
Render the area tree into the target stream and discard it.
else
break
end loop
end loop
Discard FO tree for the page sequence.
end loop
Render forcibly whatever is left in the page queue.
Write whatever is still necessary to the output stream (like
embedding fonts etc.).
As you see, once a forward reference is encountered, intermediate data
structures are simply queued up until the reference is resolved, which
adds up quickly.
There are a few more caveats, mainly that the table FO tree elements as
well as a few other FOs have references to the corresponding areas,
which cause them to hang around in memory until the FO tree is discarded
rather than having them GC'd after the page has been rendered. This is
quite bad given that blind tables are necessary for many layout tricks
and workarounds for deficiencies in 0.20.5. Not to mention for reports
consisting of a single 3000 page table.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
