Kumar Puppala wrote:

> Thanks Victor for your response. So did you have any 
> alternate approaches to resolve this issue in your application?

That depends on what you mean by "performance issue". If you have plenty of
memory, I don't think your performance speed will be adversely affected by
using one page-sequence. If you are running out of memory, probably your
least-expensive, quickest-to-implement solution is to run on a machine with
more memory. AFAIK, the commercial implementations use more memory than FOP,
but that may have changed.

Several releases ago, FOP needed to have the entire document in memory, not
just one page sequence. So the current state is a vast improvement over
that. One of the stated goals for FOP is to be able to process
page-sequences of arbitrary size, i.e. limited only by disk space instead of
memory. There have been pretty heated discussions among the developers about
how best to do this. The trick of course is to come up with a /general/
solution that works or can be made to work for all cases posed. The
constraints are significant. Consider the example of a table with auto
layout that is 1000 (or 50,000) pages long. You need to know what is going
on at both ends of that table to do the auto layout. IIUC, the three rewrite
efforts underway each use a different approach, and I don't think any of
them are yet complete, so it will be interesting to see what possibilities
develop.

I wish I had a better answer for you. Your second-best option (see
recommended option above) is probably to pick one of the rewrite efforts &
support it.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to