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

Reply via email to