[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13938998#comment-13938998
]
Vincent Hennebert commented on FOP-2293:
----------------------------------------
Well then you don't need a glue at all, but this is not my understanding of the
requirements, and it seems to be in contradiction with your comment from the
24/02. Unless you consider the case 'beginning of the page' to be different to
'middle of the page'? By 'middle of the page' I mean 'not at the bottom of a
page', which encompasses the 'top of the page' case. I admit the wording can be
misleading.
At any rate, if you don't want dynamic content to appear alone at the top of a
page, you can always set keep-with-next.within-page to 'always' on the block
before.
It's probably going to be preferable anyway, in order to avoid unexpected
behaviour.
Indeed, the appearance of dynamic content at the top of the next page will
depend on which break is selected on the previous page. It can be the break
_before_ the multi-switch, in which case dynamic content will appear on the
next page; or it can be the break _at_ the multi-switch that resolves to zero,
in which case dynamic content will _not_ appear.
Which break will be chosen depends on what follows on the document, but in both
cases the content up to that page will look exactly the same. So, you can have
one layout where the break before is selected and dynamic content appears; then
you can add a single line at the end of the document such that the break
selection changes to the break at the multi-switch, and all of a sudden the
dynamic content disappears.
Thinking about this brought another use case in my mind: you may want the first
variant to be empty, such that dynamic content appears _only_ at the bottom of
a page when there is some space, and never in the middle of it. At the moment
this is not going to work since the variant that is selected is the first that
fits. So it will always return the empty content. So you may want to change the
PageBreakingAlgorithm.handleBestFitPenalty method to return the variant that
makes the adjustment ratio closest to 0.
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,
> 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)
