--- Comment #10 from Stephan Thesing <thes...@gmx.de> 2010-01-17 23:21:03 UTC
This problem is still present in FOP trunk version.
As I see it there are several things contributing to the huge memory footprint
1) If the documents contains forward references (e.g. in the TOC or in
a "page X of Y" still footer), then FOP keeps all page sequences around,
together with the Areas until the references have been resolved
2) Even when a page has been rendered in a sequence, the FO that generated
that page is kept around, which is especially bad for tables, as they
generate quite a lot of objects for borders, etc.
It should be possible to discard a FO object as soon as all pages it
contributes areas for have been rendered.
3) At several places, page-sequences are kept around solely for computing
things like the number of pages generated so far from them.
It suffices to keep the needed information (e.g. number pages) around
On fop-dev a two pass approach has been discussed in order to solve 1):
In the first pass, no pages are rendered, only layout is done. All unknown
references are treated as "XXX" (as they are now). The definitions of
IDs are recorded for the second pass with the corresponding page number.
In the second pass, the defs from the first pass are used to resolve
references. When the definitions are encountered again in the second pass,
it is checked that they correspond to the ones made in the first pass.
For 2) and 3) an analysis and redesign has to be done in order to find all
places, where Area or FO information for a page is kept beyond the point when
the page has been rendered.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.