Hi,
Jeremias, Luca or Simon will probably be able to make the most sense
out of it, but if there's anyone else that can add a few comments, feel
free to do so.
(FYI: This is completely separate from my idea to move the
border-collapsing to the FOTree.)
Now, I'm still not fully at home in the Knuth element generation
algorithm, so I don't know exactly whether what I'm about to describe
is at all feasible/doable. Maybe it's currently already done this way,
and I'm missing the point somewhere... In that case: sorry for the
noise. :-/
Here goes:
I get the impression that the elements for borders and those for the
content of the cells are created in one single pass, which seems to be
the source of the so-called 'interaction problem' --IIC, this refers to
the situation where, for example, we have already generated the AFTER
border elements for the first two cells, while it's only when
generating the elements for the third cell that a break is triggered.
So, the obtained border- and content-elements become invalid, and need
to be re-evaluated (possibly taking the footer into account).
Is this a correct assessment of the issue?
Am I correct when I say that this problem doesn't pose itself when the
break would occur in the first cell of the row(group)?
If so, I'm wondering whether it could help if the element generation
for row(groups) were split up in two (possibly three passes) and be
made to look like the following (in pseudo-code):
while( rowIterator.hasNext() ) {
if( firstRowGroupInPageOrColumn ) {
generateBeforeBorderElements();
}
generateAfterBorderElements();
generateContentElements();
}
So, by the time we get to generating boxes/glues/penalties for the
content of the cells, we would already have the minimum/maximum widths
for *all* possible AFTER border elements in the row.
The generateAfterBorderElements() step would create two element lists:
- one to use if there is no page- or column-break
- an alternate list to use in case the content triggers a break (which
would then include all elements for the footer, if any)
Maybe both lists could be made to include the elements for the AFTER
padding as well (? since we have to iterate over the cells/grid-units
anyway).
Eventually only one of the two lists will be merged with the content
element list, depending on the situation after the content element list
completely known, but it would become a matter of inserting the right
list (and discarding the incorrect one --at least, throwing away its
elements).
The only drawback I immediately see is that the
generateAfterBorderElements() step would have to make the comparison
with the footer- or table-borders for each and every row, unless we
were to do this only in case the remaining page- or column-BPD has
dropped below a certain threshold.
The only remaining problems would then be that:
a) there may be row(groups) whose content is so large that the
remaining BPD is more than enough before the content's elements are
generated, but only drops below the threshold during the
generateContentElements() step.
b) there's always the possibility of a forced break, regardless of the
remaining BPD
The creation of the alternate element list should therefore be
implemented as a separate step that can be triggered either during
generateAfterBorderElements() or generateContentElements().
In any case, besides gaining certainty about min- or max-border-widths,
splitting up the element generation in 2-3 passes would allow us to
gain a few hints on the content to get an idea of the probability of a
page- or column-break.
I mean: without actually triggering creation of a full element list for
the content, we could maybe do a quick traverse of the FOTree-fragment
contained in each cell to see if any of its descendants have a break-*
property specified.
To make an even more educated guess, perhaps we could even perform some
off-hand calculations based on the average font-size, the number of
blocks, the number of characters of the descendant FOText nodes, the
content-height for contained images... But this all *without*
generating the elements. Only minimal communication with the actual
childLMs in that step, placing the focus on the FONode-elements (= the
list returned by TableCell.getChildNodes()) and their properties.
Does this make any sense?
Cheers,
Andreas
