[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963351#comment-13963351
]
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
multi-switch.
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?
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_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
(v6.2#6252)
