https://issues.apache.org/bugzilla/show_bug.cgi?id=45079


Andreas L. Delmelle <[EMAIL PROTECTED]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED




--- Comment #1 from Andreas L. Delmelle <[EMAIL PROTECTED]>  2008-06-01 
04:28:43 PST ---

Additional info from the related thread on fop-dev@:
---
[Vincent: ]
When the document needs 3 pages, the table in the first marker (for the
footer area) must be laid out twice, on the first two pages. And there
seems to be a bug in the marker retrieving code that returns a non-clean
table object (I suspect the columns aren’t properly set). But after
a quick look I haven’t managed to track down the bug.

[Me: ]
At first glance, the problem seems to be the fact that the ColumnNumberManager
is not cloned with the table. This means that, the second time the table is
retrieved, it will use the same one as that for the first retrieval.

If I change that little detail (Table.clone()), the example renders to three
pages without an error in FOP Trunk.

However:
- enabling assertions does throw an error (could point to that one bug that has
been fixed in 0.95 head, but has not been merged back into the trunk yet).
- looking at the result, somehow I get two retrieved markers for the footer in
the second page...
---

In the meantime, I've also corrected the second issue locally. This was caused
by the TableBody.rowGroups member which was not reset in the clone.

This leaves only the AssertionError.

BTW: for FOP 0.95 (or later) you probably want to remove keep-together="always"
from the table-rows in the header/footer. The content cannot be broken over
multiple pages anyway, and using the keep-together also forces
keep-together.within-line="always" for the content of the table-cells.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to