You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Art Welch <ar...@EASTPOINT.COM> on 2000/10/13 20:16:28 UTC

Loopy Tables

Looking for help with a table problem.

The situation is that we are using FOP to print notices that are about 8.5"
x 3.5". They have a short header and the body consists of a single row
multi-column table. Most of the data in the table is defined directly, but
one element is user supplied text. The problem is that it is possible for
the user supplied text to cause the table row to grow so that it overflows
the page. The page overflow is undesirable in itself, but it gets worse
because FOP then resets the table row and its content (undoes the layout of
the row), creates a new page and attempts to write the row to the new page.
Of course it does not fit on the new page either so... infinite loop.

Does anyone have a suggestion for a fix or work-around?

What I would like is a way to set a maximum length on a table-row (or
block-container or something inside the table-cell) and have the row
contents clipped to that area. Looking at the XSL spec I think that this
would be block-progression-dimension="length" perhaps with
overflow="hidden". I think that neither of these are currently implemented
in FOP. If there is no work around I would consider adding support for these
properties somewhere (table-row/block-container/?). First, is my
understanding of the spec accurate (block-progression-dimension="length"
would set the length of the table-row to the specified length and
overflow="hidden" would cause any resultant overflow to not be seen)? To
further complicate things I do not see overflow as a property of table-row.
In fact the most likely object that I see for accomplishing what I want is
block-container. Unfortunately, despite there being a BlockContainer class
in the FOP code, it does not appear to be wired to anything. If I were to
add rudimentary block-container support to FOP (how hard could that be),
could I then implement the block-progression-dimension and overflow
properties just for this object. Is this even possible. For a basic
implementation, wouldn't it be possible to behave the same as a basic block
(perhaps also verifying that all it's children are blocks) and add the
desired support for block-progression-dimension and overflow?

Thank You,
Art