[
https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830636#comment-15830636
]
Stephan Thesing commented on FOP-2402:
--------------------------------------
As the previous analysis already revealed, the overlap is caused by the fact
that the
page layout algorithm does not see the stretch/shrink of any glue in the lists,
as the
ListItemLayoutManager returns a "combined" list of elements for the label and
body that
only contains KnuthBlocks and KnuthPenalty elements (where the "optimum" size
of any glue is added to blocks).
When a page is broken, the adjustment of all stretchable/shrinkable glue is
computed (ratio). By this ratio, ALL glue that can shrink/stretch is to be
adjusted when the areas for the page are generated.
Now, as the page breaking algorithm does not see the stretch/shrink of the
blocks in the list items, it does not include them in the computation of the
ratio by which all glue on the page is to be adjusted.
Mostly, the page break will be computed at a point where there is some space
left at the end of the page. Then, the stretchable glue should stretch enough
to fill the page completely, not leaving an empty space at the bottom (ratio >
0 and <= 1). The ratio is computed from the difference to the page end and the
maximal available stretch of all glue on the page.
When now the areas are generated, they iterate over all the layout managers and
compute the area position and also the glue stretching, which is kept in the
LayoutContext as "SpaceAdjust" element.
When it comes to the list element, all glue in the body/label will stretch as
well, even though the amount of stretch for them was never considered in
computing the maximal stretch for the page, more glue is strech than necessary
to fill the complete page. Thus, areas will end up below the page end, as their
predecessors on the page had their glue (space-after/before) stretched more
than necessary.
as the ListItemLayoutManager does not include the stretch/shrink when creating
the combined elements for layout, it should also not stretch/shrink space when
addAreas() is called to be consistent.
The attached patch ListItemLayoutManager.java.patch does that by setting the
SpaceAdjust to 0 for the area creation for label and body.
With that "bad.fo" seems to be layouted correctly.
> 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: bad.fo, bad.pdf, footnotes-fit.pdf, FOP-2402.fo,
> FOP-2402.pdf, Simple_List.fo
>
>
> 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
(v6.3.4#6332)
