Hi, I need to use the Helvetica/Arial font-family, so there's no chance to use fixed width fonts. I never thought about using SVG instead of FOP, maybe i give it a try in future.
Meanwhile I increased the performance with FOP 1.0 with: - Splitting the tables after a certain amount of table-rows - Nesting those (new) tables in separate page-sequences - Removed the fo:markers in each page-sequence, instead added one at the start and one at the end of the document (remember: I need to handle the last page separately using those markers). The fo:retrieve-marker needs the retrieve-boundary="document" attribute here. FOP processes the 500 pages file in approx. 3 minutes using 900mb of memory. thanks for you help Matthias ________________________________ Von: Glenn Adams <[email protected]> An: Eric Douglas <[email protected]> CC: [email protected] Gesendet: Montag, den 24. Januar 2011, 16:47:26 Uhr Betreff: Re: AW: AW: [FOP 1.0] Worse performance than with 0.20.5 !? sounds like you should be using SVG, not FOP; FOP is all about making placement decisions, SVG is all about rendering to the author defined positions glenn On Mon, Jan 24, 2011 at 8:39 AM, Eric Douglas <[email protected]> wrote: If you're just printing a book as a bunch of text which does not already fit to page and throwing it into a document letting line wraps and breaks fall where they may it might look a bit funny. If you're using variable width fonts you can read the font to get character width and calculate the font size and how many rows will fit on a page based on the widest character in the set if you don't mind a bunch of whitespace. > >Oddly from reading what others have tried to do with FOP it seems no one else >has thought to use it like I do though I think my program is the best way to >use >it. I use it as a report writer. I don't use fo:table. I don't let it >calculate where to place anything on the page. I only use one standard fixed >width font set. I place all text on the document with absolute positioning. >I >use embedded code to load the custom font files (one for standard, one for >bold, >one for unicode) and programmatically generate the xml. If I want a table I >can >create empty blocks with borders or use svg line drawing to draw my own table >lines around the text. Everything fits on a page. If anything wraps to the >next page the report generating program creates a new page tag. Since it's >all >in a program it's optional if it wants to write an xml, fo, or pdf file. They >can all be passed through as bytes. The direct print option passes the pdf >through to pfdbox which generates a Pageable object for a standard java >PrinterJob. It's extremely useful if you can accept that all reports should >be >printed in Lucida Typewriter. If you want a different fixed width fonts you >just have to figure out the different font size calculation. If you want a >variable width font, absolute positioning becomes a lot more difficult. > >I love that it's so dynamic and that it doesn't generate any output until it's >done. I wrote a report with a heading block using a font size larger than the >details, which adds detail amounts which could take several pages to get total >amounts which print in the heading block on the first page. This also allows >validation before print. If there's a problem with the report program on >printing page 5 it doesn't have to print anything. > > >-----Original Message----- >From: Andreas Delmelle [mailto:[email protected]] >Sent: Saturday, January 22, 2011 1:50 PM >To: [email protected] >Subject: Re: AW: AW: [FOP 1.0] Worse performance than with 0.20.5 !? > >On 21 Jan 2011, at 08:31, Matthias Müller wrote: > >Hi Mathias > >> I temporarily disabled all images and special fonts in my fo file and >> still have the issue with the heap space. So i assume that i only have >> a chance to improve the rendering by splitting the document in >> multiple page-sequences. The thing is now, that the size of the single >> tables may vary extremely. There's also a case that i produce a table over >> 400+ >>pages !!! >> What about splitting the tables after each, let's say, 20 pages? >> Where's the best performance, less than 20? > >That could be a good start, but --it depends. It's really very difficult to >say >how many pages is ideal. >It is possible to let FOP run out of heap space with a document containing >only >a single fo:block with a dump of a chapter generating about 40 pages (or even >only 1 page --at font-size 1pt). That is, purely the layout engine's >linebreaking algorithm. No fancy fonts or tons of images. Not even a fo:table. >On the one hand, that admittedly points to a lack of scalability. >On the other, the fact remains: divide and conquer. Breaking up that same >fo:block into multiple blocks can make a world of difference. > >For the end-result, it is obviously best to break the content at a boundary >that >makes sense logically. You can try to approximate how many rows you can fit >into >one page, and try to insert breaks from there, but that will likely lead to >results that make little sense to the ultimate consumer/reader of the >document... > >> >> I almost forgot the most important point: If I split the table after >> the 20th page (or rather: after each 200th table rows (assuming ~10 >> rows per page)), how do I ensure that the page-sequence ends at the >> page bottom. The size of the rows also may vary. > >Short answer: you can't. Splitting into multiple fo:page-sequences is always a >trade-off, since it introduces a forced break that is basically arbitrary, >unless you can /make/ it so that the break makes sense there. > >Longer anwser is that one might be able to pull it off, but that would require >a >two-pass approach. In your case, that seems non-applicable, since the first >pass >will cause the out-of-memory condition. > > > >Regards > >Andreas >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] >
