I was under the impression that the breaker automatically favors break decisions that take up less space. It even goes so far that if you have a minimum="0pt" and an optimum="2opt" on a space-before, that it currently chooses "0pt" which is not so good, actually.
Well, we have several documented examples on the Wiki which we could play through to see if the breaker is likely to make bad break decisions. But I get the impression that this avoids the topic I raised. :-) I think this here is not about whether these special break conditions are favored or avoided but if they should be allowed at all. On 27.07.2005 21:54:00 Simon Pepping wrote: > 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 Jeremias Maerki
