Bug 43633 - table-cell don't render when using number-rows-spanned
Summary: table-cell don't render when using number-rows-spanned
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: page-master/layout (show other bugs)
Version: trunk
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-16 03:00 UTC by Guillaume Levrero
Modified: 2012-04-01 07:09 UTC (History)
0 users



Attachments
FO to repoduce bug. (19.49 KB, text/plain)
2007-10-16 03:01 UTC, Guillaume Levrero
Details
A minimal file to reproduce the problem (1.75 KB, text/x-xslfo)
2007-10-17 08:20 UTC, Vincent Hennebert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Levrero 2007-10-16 03:00:42 UTC
Hi,

When creating a table, five columns by 6 rows, if the first cell on row two
(cell 2-1) has a number-rows-spanned=5, the cell 1-1 is not rendered.

See FO included to reproduce.

Guillaume Levrero.
Comment 1 Guillaume Levrero 2007-10-16 03:01:19 UTC
Created attachment 20988 [details]
FO to repoduce bug.
Comment 2 Vincent Hennebert 2007-10-17 08:16:23 UTC
Hi Guillaume,

Thanks for reporting the bug. Although your test table is a bit odd since it
contains an empty row (row 2). You can work around the problem by adding an
empty cell in the row that contains the spanning cell:
<fo:table-cell>
  <fo:block/>
</fo:table-cell>
That way you will get the expected result.

For devs: at least this test is a showcase for the strange loop in
RowPainter.addAreasForCell ;-)
Since row 2 is empty (contains no cell ending on this row), no
TableContentPosition is created for this row. Thus, in
RowPainter.handleTableContentPosition, the first test is never triggered for row
2. So in addAreasAndFlushRow, the yoffset of row 2 is not recorded. And in
addAreasForCell, when the offset of the first row spanned by the spanning cell
is searched, it's not found so the while loop is triggered and the offset of the
previous row is returned instead.
As a consequence, the spanning cell, starting on row 2, gets the same offset as
cell 1.1, and overrides it.

I'll have a look at this later on, since the whole code handling empty/missing
cells needs some touch-up anyway.

Vincent
Comment 3 Vincent Hennebert 2007-10-17 08:20:41 UTC
Created attachment 20998 [details]
A minimal file to reproduce the problem
Comment 4 Vincent Hennebert 2007-12-18 11:03:23 UTC
This is fixed in rev. 605295 of the Trunk.
Comment 5 Glenn Adams 2012-04-01 07:09:10 UTC
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed