Joe Batt <[EMAIL PROTECTED]> wrote:
>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
>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

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
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]

Reply via email to