Sorry, but I don't have anything like that. I'd never do such large tabular reports with XSL-FO. If you make your current report available on the web somewhere I can take a look at what you have. That's all I can offer right now.
On 06.06.2006 09:41:47 Debasish Jana wrote: > Yes, I removed all page-number-citations. I understand that XSL-FO maynot be > tight approach. However, we are somewhat stuck in this. We need to support > high volume reports. Can you please provide a skeleton XSL-FO sample file > for showing large volume of data populated in a table? We will do the split > accordingly. > > Please help. > > Thanks and regards, > > Debasish > > -----Original Message----- > From: Jeremias Maerki [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 06, 2006 12:39 PM > To: fop-users@xmlgraphics.apache.org > Subject: Re: FOP 0.92 Beta : Performance related question > > 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]
