Which is done by {which parser?}
Xerces 2.3.4, but it doesn't matter. The problem are the generated Java objects.
80k? For how many fo:* approx. in the file?
80000 objects. A table with some twenty odd columns and 800+ rows. A TableCell, a Block and a FOText per cell. The rest is small change.
Problem seems to be one of nested little objects, no longer 'needed', but still referenced by their parent, which is still 'needed' --btw: What exactly are the criteria by means of which it is possible to decide that a given FO object, no matter how deeply nested, can safely be 'discarded' from the tree?
A) it has been rendered. B) no chance to backtrack (due to keeps, widows/orphans, side-floats, column rebalancing because of footnotes or before-floats, last page layout and perhaps a slew of less obvious reasons) Note that there are scenarios where a backtracking can ripple back through an arbitrary number of pages, although 99.99% ought to affect the current page only and even scenarios affecting the previous page look rather artificial. FOs not generating areas, in particular fo:table-column, could probably discarded immediately after the interesting info has been processed into a more amenable data structure referenced from parent FO.
[Another option (--also a very long shot maybe) would be to try and, ahem, _steal_ a little of the PDF approach... implement a form of (binary) compression on the FO tree storage in memory?
Yuck! Flashbacks of SoftRAM....
J.Pietschmann
