Vincent Hennebert commented on FOP-2293:

Hi Seifeddine,

I’ve just [applied|http://svn.apache.org/r1585822] your rev12 patch. Thanks! I 
made the following modifications:
* Test case: I removed the third page-sequence as I wasn’t sure of the interest 
of it. The first variant will always be selected and the second never since 
there is no room left on the page. Instead I changed the line-height of the MS 
3 on the previous page-sequence to 50pt, to show that the space taken up by 
previous multi-switch is taken into account.
* MultiSwitchLM: I renamed DynamicContentPosition into 
WhitespaceManagementPosition for consistency.
* Plus other minor improvements.

In PageBreakingAlgorithm.updateData2: it would be good to avoid iterating 
through the list of elements to find out the index of the penalty and compare 
it against the pageNode’s position. The index should probably be stored along 
with the variant.

I made a mistake in my previous comment I’m afraid. Only one multi-case child 
of an fo:multi-switch element may be visible at a time. So the default 
behaviour of MultiSwitchLM should be to return the elements of its first child. 
It shouldn’t be too hard to modify your default generator to do that?

Maybe it would be good to add slightly more complex tests with keeps and 
breaks, border and padding, etc. And also test the standard behaviour of 

bq. I guess everything is working fine now, but I have a concern regarding the 
case where the algorithm restarts at a MSLM position. If that happens, I think 
an exception will be thrown. Do you think that we should add a BreakElement at 
the end of the Knuth list?

What do you mean by this? When it restarts at a too short/long node because no 
feasible break has been found, or when it restarts the whole page layout 
because changing IPD has been detected?


> 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_rev10.patch, 
> FO_multi-switch_best-fit_ext_rev11.patch, 
> FO_multi-switch_best-fit_ext_rev12.patch, 
> 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_best-fit_ext_rev9.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, rev11_bug.fo, 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