Hi: We managed to prepare a XSL-FO document with physical breaking into multiple page-sequences, roughly 1,00,000 records to be shown in a table. While doing so, we split one page-sequence to hold approx. 200 records, but FOP 0.92 is failing with OutOfMemory. Increasing the heap size it performs better, but not through.
Please help by providing us some tips. Regards, Debasish -----Original Message----- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, May 12, 2006 12:15 PM To: fop-users@xmlgraphics.apache.org Subject: Re: FOP 0.92 Beta : Performance related question On 11.05.2006 10:17:36 Debasish Jana wrote: > Hi: > > I have a question related to performance issues. How large an xsl-fo file > can be? How large volume it can support? Depends on how much memory you can provide. But that's the wrong question in my opinion. The question should be: Is XSL-FO the right approach to generate huge but simple tabular reports? My answer is no in many cases as has been discussed on this list before. > I have an application that fetched approx. 60,000 records fetched from > database an populates in a fo:table-cell as text. Basically, it uses the > following block of fo-tags repeatedly to populate a huge chunk of data. > > ------ > <fo:table-row height="42pt" > > <fo:table-cell > > > <fo:block><fo:block text-align="left"> > <fo:inline ...> > Some data > </fo:inline> > </fo:block> > </fo:table-cell> > </fo:table-row> > ------ > > My specific questions are: > > - Can you suggest a shortcut so that fo-tags can pull data from the database > directly? That's not how XSL-FO works. Not an option. > - What is the best suggested approach to handle large volume of data passed > embedded inside fo-tags? Get rid of everything unneccessary, like the nested blocks and the inline that you're showing above. Every nesting level eats memory. > We can think of the following: > > - Have a streaming fo input to the FOP renderer to generate PDF. Can you > provide a sample code to handle FOP rendering to PDF from a FO file through > streaming? Depends on what you mean by streaming. FOP is built to accept a SAX stream, so if you're building a DOM for the FO document and then pass that to FOP you're giving away memory. Rework your system to create SAX directly as demonstrated here: http://xmlgraphics.apache.org/fop/latest/embedding.html#examples While FOP processes a document internal trees are built which essentially cancels the effect of streaming for large page-sequences especially since FOP is not optimized for large page-sequences, yet. > - We were reading a link in FOP documents, it says "To minimize the amount > of memory used by FOP, we wish to recycle FO Tree memory as much as > possible. There are at least three possible places that FO Tree fragments > could be passed to the Layout process, so that their memory can be reused: > > fo:block , fo:root and fo:page-sequence > > Could you please clarify with some supporting examples or some link that we > can read to get the guideline? There may be something in the mailing list archive but essentially this means you have to do most of the page breaking process yourself in XSLT by predicting when a page is full and then use page-sequences to divide the document. FOP can currently only free memory after a page-sequence is complete and that's why you need to create multiple smaller page-sequences. > My last question: Is FOP designed to handle large volumes like this? At the moment, FOP is not optimized to handle large volumes. The recent focus has been on functionality. The architecture is prepared to handle large volumes but to really cope with them additional work is needed. > Please reply soon. We are standing of major decision based on your answer. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
