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 

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


> 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

Reply via email to