One thing that IMHO is still lacking in the table breaking code is penalty values. ATM all penalties are 0. I believe the penalty value should depend on the extra vertical size that the break contributes, that is, on the penalty's width. I have no idea about the multiplication constant, nor if it should be linear or quadratic. I am not sure if it avoids the current case, but it is surely needed in order to favour better breaks over worse ones.
Simon On Wed, Jul 27, 2005 at 08:45:48PM +0200, Jeremias Maerki wrote: > 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 -- Simon Pepping home page: http://www.leverkruid.nl
