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]