[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Hennebert updated FOP-2293:
-----------------------------------
Attachment: empty-last-page.fo
bq. All I'm saying is that I prefer not to see any empty space in my document
which may force FOP to make an extra page for nothing, because this is what
actually happens if a dynamic content didn't fit in a page.
Do you have a test case that illustrates this behaviour? I found one but this
doesn't happen because of the glue. See attached file: the first variant is
bigger than the second one, and doesn't fit on the page. So the second variant
is selected as a feasible break and the algorithm carries on as usual. Except
that there is nothing to display on the next page. There is just the zero-width
box that is there exactly because otherwise dynamic content would be ignored
altogether when it's last on the page sequence.
This is a tricky case. I don't really see any way of getting out of this
without forcing the Knuth algorithm into following a path it's not designed for.
The best solution probably is to introduce some constraints on the dynamic
content: make sure that the first variant is always the smallest, and change
the PageBreakingAlgorithm.handleBestFitPenalty method as I suggested in my
previous comment to select the variant that leads to an adjustment ratio
closest to 0.
That way, there will be a feasible layout without an empty last page. The
layout with a page break at the multi-switch and an empty page will still
exist, but the version that doesn't break at the multi-switch, uses the glue
instead and carries on to the end of the content will be preferred since it
will use less pages. This can be illustrated by inverting the two variants in
the attached file.
The enforcement can be informal. That is, document it and warn the user that
unexpected things may happen if the recommendation is not followed. Or it can
be programmed: throw an error, or issue a warning and add an empty variant at
the beginning of the list, etc.
bq. I have a tricky problem regarding the treatment of space elements inside a
dynamic content. Since each variant's Knuth list is stored separately inside
the best-fit penalty, there is no way for the space resolver to have any
information about surrounding elements and each variant is resolved
independently.
I don't think there is an easy way of solving this. The space resolver works on
a whole sequence of Knuth elements and does all the resolution in one go.
What you need is partial resolution: on the elements that precede the
multi-switch, on the elements inside the multi-switch, on the elements after
the multi-switch. Then you would finish the resolution in the breaking
algorithm, once you know which variant is selected.
This is the same problem as for footnotes, which I'm mentioning in my comment
from 2013/11/20. Refactoring space resolution to achieve this is IMO not
trivial, and should be left as is.
If a space is needed at the beginning of a variant, this can be achieved by
setting space-before.conditionality to 'retain' (in theory: I had an error when
I tried it, which should be fixed).
HTH
Vincent
> Whitespace management extension
> -------------------------------
>
> Key: FOP-2293
> URL: https://issues.apache.org/jira/browse/FOP-2293
> Project: Fop
> Issue Type: New Feature
> Components: general
> Affects Versions: trunk
> Reporter: Seifeddine Dridi
> Priority: Minor
> Labels: XSL-FO
> Fix For: trunk
>
> Attachments: FO_multi-switch_best-fit_ext_rev2.patch,
> FO_multi-switch_best-fit_ext_rev3.patch,
> FO_multi-switch_best-fit_ext_rev4.patch,
> FO_multi-switch_best-fit_ext_rev5.patch,
> FO_multi-switch_best-fit_ext_rev6.patch,
> FO_multi-switch_best-fit_ext_rev7.patch,
> FO_multi-switch_best-fit_ext_rev8.patch, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, bestfit.fo, doc.pdf,
> empty-last-page.fo, multi-switch-testcases.zip, multi-switch_bestfit.fo,
> multiple-feasible-nodes.fo, patch-rev1.1.patch, patch-rev1.patch,
> patch-rev2.patch, patch.patch, two-valid-variants.fo
>
>
> I have been working on an extension for whitespace management, similar to
> what's described here:
> http://wiki.apache.org/xmlgraphics-fop/WhitespaceManagement
> The logic of the extension is very simple: the user defines a set of
> alternatives that he wishes to insert at the end of a page, then if there is
> enough space left, FOP will pick the alternative that best matches the user's
> selection criteria (first fit, smallest fit, biggest fit).
> This is my first work on FOP and it took me almost 2 months to reach this
> stage in development. But it's not the end of course, so I'm relying on your
> feedback to improve it.
> Thank you
--
This message was sent by Atlassian JIRA
(v6.2#6252)
