On Dec 7, 2005, at 16:12, Clifton Craig wrote:
Hi,
Thanx for your reply. Yes I do want to ultimately make it look like
it did
when I just dumped the entire report body under one page sequence,
however I
cannot use one page sequence due to memory overflow issues.
I'm still a little concerned as to why I'm having memory overflow
if it is the norm to
use one page sequence for the report body as I've done.
The explanation for the excessive memory use, AFAIU, is that the
Table object holds a list with references to its childNodes, and
every childNode again has such a list, etc.
As long as the Table is referenced, *all* of its descendant nodes
will remain referenced, so if you have a large table with about 20
columns and 1000 rows, and the contents of the cells are plain simple
blocks, then keeping this table together in one page-sequence,
possibly means 20000 cells in memory plus *all* nodes for their
content (so, a minimum of 20000 blocks and *all* their character data)
Given that FOs by definition are compound objects (and not all their
members are primitive types), you can try to do the math... and that
is only the FO-tree side.
Since the handles to the FOs are released only at the end of each
page-sequence, splitting the table over multiple page-sequences is
currently the only way to keep it manageable. (in both versions of FOP)
(Side-note: somehow it should be possible to release the objects for
the cells and their content once we're absolutely certain that they
will no longer be needed. Determining that, however, doesn't seem to
be as simple as it sounds, since layout may involve backtracking
several rows...)
As for my stylesheet, I'm not offended at all from your comments
rather I'm just not as concerned
on that part of it. The end result would be the same no matter what
technique
I used in XSLT and the performance of the stylesheet is acceptible
when I use
Xalan directly to produce FO.
OK, my remarks were related more to style than efficiency. In your
case, I'm guessing there is no noticeable performance benefit to my
suggestions... It just 'rhymes' better with the XSLT way of doing
things (apply templates to node-sets).
The only big question here is, "Can I get away with using one page
sequence or do I have to use multiple page sequences?"
Oh, you *can* get away with using one page-sequence, but only if you
have a massive heap at your disposal...
Another equally big question is, "How do I go about using multiple
page
sequences effectively if I have no other option?"
Well, you mentioned line-counting. How do you go about that exactly?
Does this number of lines correspond to a number of elements in your
source XML? In that case, you're probably best off using XSLT
grouping techniques[*].
If you know in advance how many rows will fit on a page, you could
even create one page-sequence per page (one table per page), which
should reduce the memory consumption drastically.
[*] see: http://www.jenitennison.com/xslt/grouping/index.xml
HTH!
Cheers,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
