[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955050#comment-13955050
]
Vincent Hennebert commented on FOP-2293:
----------------------------------------
Hi Seifeddine,
at first I was doubtful that your approach would work, but after a more
in-depth study I think it should do the job. It’s actually quite clever and
we’re at the edge of what we can do with the Knuth algorithm; hopefully it
won’t cause conflicts with other features but as of now I can’t see any. Well
done anyway!
A few comments:
* In BestFitPenalty: this penaltyIndex field should ideally be removed as it
introduces unwelcome mutability. IIC all you need is a reference to the
BestFitPenalty instance? In which case you can probably just turn Variant into
an instance class (remove the static keyword) and add some getPenalty method
that return BestFitPenalty.this
* In PageBreakingAlgorithm:
* Isn’t the javadoc for pendingVariant misleading: is it all descendant nodes
or just the next one?
* BestPageRecords: there’s no need to override reset AFAIU?
* computeDifference: you should also add the size of the pending variant if
{{element}} is a glue (although I don’t believe it ever happens in page
breaking that we are breaking at a glue since they are always preceded by
penalties —but better safe than sorry).
It remains to make it work when there are several multi-switch on the same
page. IIC it doesn’t work at the moment. Maybe you can take advantage of the
fact that the first variant will be the one that will be selected by default.
So only when we break at a BestFitPenalty do you need to know what variant has
been selected if any. Then, on active nodes, instead of storing the pending
variant, you can just add the widths of the variants that are on the page.
Thanks for your patch!
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_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, 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)
