Andreas L. Delmelle updated FOP-2402:
Just a bit of further info:
As far as I can see, the assessment in the previous comment is roughly correct.
It is definitely related to the stretchable spaces, and it seems indeed like
the breaks are calculated using the minimum or optimum, while the maximum is
eventually used, which then leads to the overlap.
Replacing the stretchable spaces with fixed ones also avoids the bug from
manifesting. Either the last footnote is shifted to the next page (when using
the maximum), or everything fits nicely (using the minimum or optimum values).
See also attached for a more reduced sample, which already shows the bug
manifesting, but you admittedly do need a good pair of eyes to see it, as it
seems to be a matter of a couple of pt there.
Added background-colors for additional clarity. Looking carefully, two things
* the yellow background of the footnote overlaps a tiny bit with the red of the
last list item.
* on the second page, the blue background, which corresponds to the spacing, is
slightly less than it is on the first, even though there would be more than
enough room there to use the maximum value.
Looking at the area tree XML reveals that, indeed, for the first page the
maximum value of 6pt for the space-before is used, while it is the optimum
value of 5pt on the second page...
> footnotes overlap regular content
> Key: FOP-2402
> URL: https://issues.apache.org/jira/browse/FOP-2402
> Project: FOP
> Issue Type: Bug
> Components: layout/block
> Affects Versions: trunk
> Environment: Ubuntu 14.04, Java 1.7.0_55
> Reporter: Alexey Neyman
> Attachments: FOP-2402.pdf, bad.fo, bad.pdf, footnotes-fit.pdf
> We've noticed yet another issue with the rendering of the footnotes where the
> footnote is rendered over the regular content. Verified with top-of-trunk
> FOP, r1615966. Please refer to the attached FO/PDF files.
> Curiously, if the last fo:list-item is commented out, the preceding
> fo:list-items are placed more tightly and as a result, the footnotes do not
> overlap with the regular content. This suggests that there's a bug in how the
> space between blocks is calculated, but I haven't debugged it further yet.
This message was sent by Atlassian JIRA