[ 
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960325#comment-13960325
 ] 

Vincent Hennebert commented on FOP-2293:
----------------------------------------

bq. I think I have to filter out variants when updateData2() is called in such 
a way that a penalty can only be activated if its position is less than the 
current node position.

Indeed, something like this might work.

bq. Regarding the name of the extension, I agree with you that the name 
"best-fit" is a bit misleading and does not accurately describe what the 
extension is doing. I suggest "first-fit" or "first-fit-within-active-page".

Are you talking about the value for auto-toggle here? "first-fit" makes sense 
but again, it might too easily be mistaken for one of the various layout 
methods (first fit, best fit, total fit). Maybe just "first-fitting"?

bq. About the name of the penalty, what about MultiSwitchPenalty? The BFP is 
supposed to be only used by MSLM anyway...

But a standard implementation of multi-switch wouldn't use such a penalty. 
Maybe rather WhitespaceManagementPenalty or something like that.

bq. Yes. If auto-toggle was not set, all FO multi-case will be rendered. In 
such a case, maybe it would be better to fire an exception and tell the user 
that FO multi-switch is not yet supported?

How easy would that be to simply show all of the multi-case children? It this 
is doable in a reasonable amount of time it should be done this way. What 
bothers me a bit right now is that the auto-toggle property is not used at all, 
so we have the extension behaviour by default. It would be better to trigger it 
only when auto-toggle is present.

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

Reply via email to