[
https://issues.apache.org/jira/browse/FOP-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651355#comment-13651355
]
Vincent Hennebert commented on FOP-2222:
----------------------------------------
This issue indeed corresponds to what is described in that 'Known Problems'
section; it has nothing to do with column balancing.
Column balancing was about better taking into account the properties of boxes,
glues and penalties: mainly, include the height of a penalty when breaking
there, and discard glues and penalties that follow a break up to the next box.
This problem has to do with Knuth elements not accurately representing the
actual content. It is described into more details at the following page:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnownProblems
Fixing it requires an intimate understanding of the box/glue/penalty model and
the breaking algorithm. Departing from that algorithm would actually be
necessary, as we would have to deal with different sequences of Knuth elements
depending on where we break in the table. Given that the algorithm is all about
considering several feasible breaks in the same time, those Knuth sequences
would have to be dealt with simultaneously, in a compartmented way.
Basically that issue shows that while the box/glue/penalty model is great to
simulate a paragraph, it is not suited for more complex material like tables,
that are made of loosely coupled columns of content. Between the
synchronization points that row boundaries represent (more or less —you can
also have row-spanning cells), the layouts of the different cells can vary
widely.
I think I'd rather try and find a way to work around this issue by designing
the document differently...
> Incorrect page break in cell
> ----------------------------
>
> Key: FOP-2222
> URL: https://issues.apache.org/jira/browse/FOP-2222
> Project: Fop
> Issue Type: Bug
> Components: page-master/layout
> Affects Versions: 1.1, trunk
> Reporter: Nico
> Attachments: test-two-cells.fo, test-two-cells.pdf
>
>
> In a table with one row and two cells, spanning across multiple pages, the
> pages break are not what should be expected. (I don't know if it's by design
> or a bug).
> Please see the attached .fo and .pdf.
> Test case : the first cell has blocks with 120mm height. The second cell has
> blocks with 100mm heights. The page height is 266mm
> First page : each cell contains his two blocks on the page
> second page : after the first page break, the fist cell show only the one
> block where two is expected. The second block, which is on page 3, should fit
> on page 2.
> Is it standard behaviour ? Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
