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 <edoug...@blockhouse.com>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:andreas.delme...@telenet.be] > Sent: Saturday, January 22, 2011 1:50 PM > To: fop-users@xmlgraphics.apache.org > 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: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org > For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org >
