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]
PDFTest.pdf
Description: PDFTest.pdf
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
