I got a test case for tables which raises not a technical but rather a interesting conceptual question. Please have a look at the attached test case. It defines a table with two columns and two rows. In the given setup the second row creates an break decision with the current code that can be argued as being bad (see the PDF). Here's an excerpt from the element list:
8) box w=9600
9) penalty p=0 w=0
10) box w=28800
11) penalty p=0 w=0
12) box w=0 //<-- this is where the second row starts
13) penalty p=0 w=9600 //this penalty is due to the possible break after "B"
14) box w=28800
15) penalty p=0 w=0 //this is the next break poss after three lines
//due to the orphan setting
16) box w=28800
While working on element list generation for tables I came across this
question and decided not to do anything about it, especially since
removing some of these break possibilities might not be desirable in all
cases.
A rule that could be easily implemented would be that we allow the first
break possibility only after every cell in a new row contributed at
least one of its own boxes to the combined element list.
An example: If you look at page 1 of [1], step 1 would over ignored. On
page 3 of [1], the steps 1 and 2 would be ignored.
[1] http://people.apache.org/~jeremias/fop/KnuthBoxesForTablesWithBorders.pdf
With this rule the element list would look like this:
8) box w=9600
9) penalty p=0 w=0
10) box w=28800
11) penalty p=0 w=0
12) box w=28800 //<-- this is where the second row starts
13) penalty p=0 w=0
14) box w=28800
I'm unsure ATM what this would mean for cases with row spanning, though.
I can see that this new rule would make this better in most cases. What
worries me is that there might be cases where we wouldn't want that
behaviour, although ATM I can't see them. So I just want to check with
you that I haven't forgotten about anything. Or maybe someone has a
better rule to implement this. Thoughts welcome.
Jeremias Maerki
table-body4.xml
Description: Binary data
table-body4.xml.head.pdf
Description: Binary data
