Joe Batt <[EMAIL PROTECTED]> wrote: >Joerg, >What did you mean by this >-- >FOP is not generally slow but under certain circumstances. >Try to use the FOP command line application to render your PDF and >watch the output. If you get lots of overflows, indicated by a ">" >or an "INFO: >" line, you'll have to fiddle with column widths and >maybe hyphenation to make this go away. You may also want to check >"keep-together" attributes and such stuff that could cause FOP to >iterate. >-- > >I had no idea that all those '>'s meant something.
It's documented somewhere. If '>' appears, it means that the processor encountered difficulties while laying out a page and that your output might look ugly or at least not as you planned. > What do you mean by overflows? What do you mean by 'cause FOP to iterate'? Simplified and from hazy memory: A FO processor reads the FO input, then it tries to determine where on the pages which text and graphics has to be placed. In order to achieve this, the text and graphics is placed in little boxes, and constraints for their size and position are determined from the structure and attributes of the FO in the source. It may be somewhat difficult or even impossible to determine the size of a box around a particular text snippet. For example, if you have a table with a column 20pt wide, and a cell in this column with averyveryveryveryveryveryloooooongword, which, when rendered, is wider than the column width. This is called "overflow". There are other overflows possible when the processor places tentatively a text box at a certain place, and finally discovers the text doesn't fit the box, for example a table cell which is placed near the bottom of a page and which contains a block with a lot of text. Rather then breaking the page in the middle of the block, it is spilled over to the next page. There are situations where you can make it very difficult for the processor, for example by including a graphic higher than the page body. Because it won't fit ever, the processor tries to spill it onto the next page until it runs out of memory... > I'm seeing a 30-100 page table generated in 5-15 minutes and > frequently running out of memory even though I set the heap size > to 1GB. I had this symptom too when i started. Check whether you generate table cells which are approaching the height of a page, either by having a lot of text in it or by including a lot of space. FOP appears to be unable to split table cells, probably because it requires the content of a table cell wrapped in a single fo:block (some comments from the developers?) You could try: - Enable hyphenation: <fo:block hyphenate="true" language="en"> or something. This will fit more characters on a line and may thereby reduce table cell height. - Split long texts over multiple rows, thereby ease the task of FOP to fit the cells onto a page. Not exactly easy to solve in general, but your data may permit a simple solution (for example if long texts appear only in a certain column). If you really have difficulties and you cannot hire a more advanced expert, you'll probably have to study the XSL-FO specification and the FOP documentation in detail by yourself in order to get further hints. And, well, FOP is not exactly programmed to use as little space as possible. Stuff is copied a lot and often still hangs around in memory long after it isn't needed anymore, though this improved with 0.20's stream rendering. Joerg Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
