# Re: Element list generation for tables (special case)

```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