Re: Element list generation for tables (special case)

[Andreas L Delmelle]

Sorry, forgot the attachment...

table-body4b.xml.head.pdf
Description: Adobe PDF document

On Jul 27, 2005, at 23:26, Andreas L Delmelle wrote:

On Jul 27, 2005, at 20:45, Jeremias Maerki wrote:

Hi,

I got a test case for tables which raises not a technical but rather a

case. It defines a table with two columns and two rows. In the given

can be argued as being bad (see the PDF).

interesting conceptual question. Please have a look at the attached test setup the second row creates an break decision with the current code that

Indeed, doesn't look right. Given the value for the orphans property, one still would reasonably expect the break to occur before the first cell of the second row. BTW: tried adding a third column mirroring the first, and this leads to ONLY the second column being moved to the next page... This as a further demonstration that the currently produced result still leaves a bit to be desired. (see attach)

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

14) box w=28800

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

cases.


break possibility only after every cell in a new row contributed at
least one of its own boxes to the combined element list.

13) penalty p=0 w=9600 //this penalty is due to the possible break after "B" 15) penalty p=0 w=0 //this is the next break poss after three lines removing some of these break possibilities might not be desirable in all A rule that could be easily implemented would be that we allow the first

So IOW, if I get this correctly: all break possibilities are to be considered preliminary until the last cell occupying this row (= last grid-unit in the row) has been taken into account?

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

I'd think the first, but just want to make sure...




Or modify all boxes' widths (=heights) to be equal to the largest box.


IIC, the two separate element lists for the second row would be:

First grid unit:
1) box w=9600
2) penalty p=0 w=0

Second grid unit:
1) box w=28800
2) penalty p=0 w=0





Then combine the lists to arrive at the result below:

Hmm... Do you mean that the steps would be performed but their results discarded, or that the steps simply would not be performed at all? Are the break possibilities currently considered only at the level of the table body --so the element list contains the elements for the cells' boxes, but no separate elements/indicators of row-boundaries? In that case --with the risk of underestimating the complexity of what I propose--, perhaps an alternative to the suggested rule would be to insert a step that combines the generated boxes/penalties only after the element list for the last grid unit in a logical row has been created (?) Anyway, instead of simply ignoring those steps, we could also increase the penalty value for the offending break possibility (currently: p=0 for all of them) So, IOW, for each row, store the element lists, and after all lists are available, review the calculated penalty values, increasing them when a given break possibility has undesirable consequences when the other element lists for the row are taken into account. Or the other way around: give them a default penalty value that is high enough, then afterwards decreasing them for the most favorable break possibilities. After this step is completed, add the combined element list to the body. So, compare the first boxes' widths and, since the first box in the first list is smaller than that in the second list, either increase the penalty value for the second step in the first list, or change the width of the first box in the first list. Maybe the latter is more attractive, since the resulting combined list can then be created by concatenating the two separate lists... [Admitted: this particular case is rather simple, since both lists only have one box.]

With this rule the element list would look like this:

<snip />

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.

As long as the criterion is that every _grid unit_ for the (logical) row in question must have contributed at least one box, I wouldn't expect any particular problem.

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.

Greetz,

AD

Greetz,

AD