Did you remove all page-number-citations? Without getting my hands on your documents I don't have any further ideas for you. You may need to accept that XSL-FO may not be the right approach for what you're doing as I have told you before.
On 06.06.2006 08:51:45 Debasish Jana wrote: > 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]
