[
https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141518#comment-15141518
]
Andreas L. Delmelle edited comment on FOP-2402 at 2/12/16 7:16 PM:
-------------------------------------------------------------------
More info:
As I was playing with the sample, trying to reduce it further to the absolute
minimum required to trigger the bug, I noticed that the nested list structure
is also a factor, i.e. removing the outer list also resolves the spacing issue.
Using either a regular block or a table instead of a list, the issue cannot be
reproduced.
All the space specifiers can be removed, save for those on the list-items.
Guess it will be key to determine exactly what differs in processing between a
plain one level list, and a nested list structure, where one list is an item in
the other.
EDIT - In the meantime, I have traced said difference to the space adjustment
ratio that is used when adding the areas. The page-breaks themselves are
computed using the optimum space, so nothing wrong there, but it is only when
adding the areas that the space is stretched, based on the adjustment ratio
assigned to the break possibility.
For some reason -- I am not quite there yet -- that ratio, in case of a nested
list, is 1.0, which results in the full amount of stretch being applied. This
basically comes down to: space-before.maximum is used.
When the outer list is removed, the adjustment ratio when adding the areas for
that same list item is only 0.05, which results in a much smaller stretch,
which makes everything fit nicely.
Still TODO: dive deeper in the page-breaking algorithm to find out why exactly
this adjustment ratio is much higher in case the list is nested.
EDIT 2 - Aha! I think I see the big difference now... In case of the nested
list, the page-breaking algorithm is run over a smaller list of combined
elements, where the first box is 12pt -- space-before discarded -- and all
following boxes are 17pt (= 12pt + 5pt). The list has no glues, i.e. from the
point of view of the algorithm there is nothing to stretch/shrink at the given
page-break position, and it is all-or-nothing.
In case the list is not nested, the page-breaking algorithm gets to see the
full set of elements produced by the list, which has the spaces neatly
represented by glue elements, which allows the algorithm to play with
stretch/shrink at each break position.
was (Author: adelmelle):
More info:
As I was playing with the sample, trying to reduce it further to the absolute
minimum required to trigger the bug, I noticed that the nested list structure
is also a factor, i.e. removing the outer list also resolves the spacing issue.
Using either a regular block or a table instead of a list, the issue cannot be
reproduced.
All the space specifiers can be removed, save for those on the list-items.
Guess it will be key to determine exactly what differs in processing between a
plain one level list, and a nested list structure, where one list is an item in
the other.
EDIT - In the meantime, I have traced said difference to the space adjustment
ratio that is used when adding the areas. The page-breaks themselves are
computed using the optimum space, so nothing wrong there, but it is only when
adding the areas that the space is stretched, based on the adjustment ratio
assigned to the break possibility.
For some reason -- I am not quite there yet -- that ratio, in case of a nested
list, is 1.0, which results in the full amount of stretch being applied. This
basically comes down to: space-before.maximum is used.
When the outer list is removed, the adjustment ratio when adding the areas for
that same list item is only 0.05, which results in a much smaller stretch,
which makes everything fit nicely.
Still TODO: dive deeper in the page-breaking algorithm to find out why exactly
this adjustment ratio is much higher in case the list is nested.
> 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.fo, 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
(v6.3.4#6332)
