https://issues.apache.org/bugzilla/show_bug.cgi?id=51874
--- Comment #2 from Vincent Hennebert <[email protected]> 2011-10-12 16:34:13 UTC --- Created attachment 27765 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27765 Simplified FO file showing the issue Thanks for your bug report. After some investigation I managed to reduce the size of the problematic table to just 3 rows and 2 columns. What happens is that a table-cell spanning two columns overlaps with a cell from the previous row that spans two rows. There is a bug in the table code (package o.a.f.fo.flow.table) that doesn't check for this kind of situation. It's not entirely clear what should be done: either throw an error about the overlap, or move the cell to a later column such that two consecutive slots are available; this would lead to a hole in the table (a missing fo:table-cell element). The bug shows up in o.a.f.layoutmgr.table.RowPainter.addAreasAndFlushRow. The grid unit at row index 1 and col index 1 (corresponding to cell 1.2) is later overridden by cell 2.1's grid unit. So cell 1.2 never gets a chance to properly 'shut down' and reset firstCellParts[1]. Which leads to the AssertionFailedError when cell 3.2 tries to register its first cell part in this variable. As mentioned above the algorithm that places cells on the table grid must be made more robust. However, this problem occurs with rather rare and complicated tables, so fixing it would be considered low priority. The best thing to do probably is to avoid the error by filling the holes in the table with empty fo:table-cell elements (i.e., that contain an empty <fo:block/>). This way, the cell placement algorithm cannot be confused. Or maybe the table-cell is not actually meant to span two columns. HTH, Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
