[
https://issues.apache.org/jira/browse/FOP-2402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146232#comment-15146232
]
Andreas L. Delmelle commented on FOP-2402:
------------------------------------------
Some further musings on this issue:
Seems like the best option would be to do some minor refactoring of the list
layout code (in ListItemLayoutManager).
I am currently thinking of, as a first step, introducing a ListItemStepper, to
stress the analogy between lists and tables -- there already is a TableStepper
--, then see if this triggers new insights into potential simplifications of
the code. That new class can hold some of the logic that is currently in
getCombinedKnuthElementsForListItem() and getNextStep(), in an attempt to make
the former method a bit easier to grasp.
It will definitely be tricky to get it all right, though. The case as presented
here is rather simple, since the label is empty. This should normally yield the
same output as a two-column table, with a zero-width first column.
In most cases, the label will consist of a single part, which will still not
add too much complexity. The main focus will be the multi-part body content.
The point where it gets really interesting is where a list is really used as a
two-column table. If both label and body have multiple parts _and_ those parts
have stretchable spaces with different widths, we somehow need to generate one
or more "combined" glue elements that have the appropriate effect when the
layout algorithm is run over it...? I can imagine that this may be one of the
reasons why the table layout code currently simply converts all stretchable
glues into non-stretchable ones ( ? )
> 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)
