[ 
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:38 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.

EDIT 3 - So, the actual root cause of the problem is that a sequence of 
glue-box produced by a nested LM is merged into a single box. If we can avoid 
that from happening, it should be solved. The table layout code seems to handle 
this slightly better, as in: it does not merge glue-box sequences into a single 
box, but there I noticed that the glues are somehow returned as 
non-stretchable, which would result in a tiny amount of space between the last 
list item on the first page and the footnotes.
Only in case of a plain block parent is the result as expected (no matter how 
many levels are nested), because the block LM always returns the sequence it 
receives from its child LM, with only minimal additions in case the block has 
borders or spaces set. It does not combine anything.


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.

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.

> 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)

Reply via email to