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 

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 

It's probably going to be preferable anyway, in order to avoid unexpected 

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.


> 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

Reply via email to