[
https://issues.apache.org/jira/browse/FOP-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791302#comment-13791302
]
Seifeddine Dridi edited comment on FOP-2293 at 10/10/13 8:17 AM:
-----------------------------------------------------------------
Sorry about the inconvenience. Didn't know the patch was missing files...
{quote}
BestFit.filter: why would you want to remove children FO nodes? Seems to me
like you just want to somehow select the right one.
{quote}
That is going to change, since modifying the FO tree is not recommended after
all (see Glenn's comment). I'm still searching for other solutions to
incorporate the best-fit extension. Maybe I'll integrate the code of
_BestFitLayoutManager_ directly inside _MultiSwitchLayoutManager_.
{quote}
MultiCase.isActuated: are you sure about the test? Do you want to implement
this method at all? In the case of your extension there will be no actuation.
{quote}
The purpose of that method is to check whether the multi-case in question has
been actuated by a multi-toggle or not. It has nothing to do with the
_best-fit_ extension...
{quote}
MultiSwitch.finalizeNode: the selection of the best node cannot be done here?
You have to wait for the results of layout?
{quote}
Right, but without the extension we can find out the currently visible
multi-case early on.
{quote}
MultiToggle: why do you implement a filter method in this class? From what I
understood you're not going to use that element in your extension. Therefore
you don't have to implement it. Otherwise you have to test it...
{quote}
the multi-toggle is responsible for actuating its parent multi-case. It works
based on the currently visible multi-case and the switch-to property. Please
have a look at the newly attached patch.
In case you didn't notice, I removed the old test case in
_KnuthAlgorithmTestCase_ because it doesn't work anymore and so many things
have changed. I'm planning to add new test cases, but right now I want to focus
on improving the core logic of my extension, because the current implementation
has many limitations (no support for stretching/shrinking of glues, no support
for IPD size, etc..) and it doesn't fit very well with the rest of the layout
engine.
Thanks for your review
was (Author: sdridi):
Sorry about the inconvenience. Didn't know the patch was missing files...
{quote}
BestFit.filter: why would you want to remove children FO nodes? Seems to me
like you just want to somehow select the right one.
{quote}
That is going to change, since modifying the FO tree is not recommended after
all (see Glenn's comment). I'm still searching for other solutions to
incorporate the best-fit extension. Maybe I'll integrate the code of
_BestFitLayoutManager_ directly inside _MultiSwitchLayoutManager_.
{quote}
MultiCase.isActuated: are you sure about the test? Do you want to implement
this method at all? In the case of your extension there will be no actuation.
{quote}
The purpose of that method is to check whether the multi-case in question has
been actuated by a multi-toggle or not. It has nothing to do with the
_best-fit_ extension...
{quote}
MultiSwitch.finalizeNode: the selection of the best node cannot be done here?
You have to wait for the results of layout?
{quote}
Right, but without the extension we can find out the currently visible
multi-case early on.
{quote}
MultiToggle: why do you implement a filter method in this class? From what I
understood you're not going to use that element in your extension. Therefore
you don't have to implement it. Otherwise you have to test it...
{quote}
the multi-toggle is responsible for actuating its parent multi-case. It works
based on the currently visible multi-case and the switch-to property. Please
have a look at the newly attached patch.
In case you didn't notice, I removed the old test case in
_KnuthAlgorithmTestCase_ because it doesn't work anymore and so many things
have changed. I'm planning to add new test cases, but right now I want to focus
on improving the core logic of my extension, because the current implementation
has many limitations (no support for stretching/shrinking of glues, no support
for IPD size, etc..) and it doesn't fit very well with the rest of the layout
engine.
Thank for your review
> 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: bestfit.fo, doc.pdf, FO_multi-switch_test.fo,
> FO_multi-switch_with_best-fit_extension.patch, multiple-feasible-nodes.fo,
> multi-switch_bestfit.fo, patch.patch, patch-rev1.1.patch, patch-rev1.patch,
> patch-rev2.patch
>
>
> 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.1#6144)
