Thinking more about it, it appears that it is not so trivial ;-).
Lacking of time to do a proper implementation, I decided to write down
my ideas on a wiki page [1]. It's not complete yet, I'll try to add
thoughts later on.

In short, I agree with you that only playing with demerits actually is
not enough like I first thought. And also that we should be as few
restrictive as possible when discarding layouts, because we will always
find problematic documents for which there is not many solutions.


[1] http://wiki.apache.org/xmlgraphics-fop/FootnotesAndBeforeFloats

Luca Furini a écrit :
> Vincent Hennebert wrote:
>> Hi Luca,
> Hi!
>> I had a look at your patch and have several comments:
>> - I see you re-enabled the noBreakBetween method; I don't think it's
>>   a good solution because it artificially prevents some nodes to be
>>   created, which even if bad may be necessary for some complex
>>   documents. See for example the attached fo file.
> Right, it is quite an unlucky document!
> Anyway, I still think that a footnote should be placed in a page
> following its citation only if there isn't really any other option: for
> example, the citation is inside a large block of unbreakable text, and
> the footnote itself is a large unbreakable block, and their cumulative
> height is taller than the page height (a situation that will surely
> happen sooner or later ;-) , but is quite more unlikely than your example).
> I think your example would not look so bad in the context of a page with
> some book-like width and height: yes, there would be quite a large space
> between the last content line and the first footnote line, but I think
> many users would prefer such an output to one having the footnote placed
> in the following page.
>> I also documented
>>   a similar problem on the wiki [1]. While it makes the testcases work
>>   it actually creates some bad layout in other cases.
> The one in the 4.1 / footnote section? It's a very interesting one,
> although I think it's quite another story.
> While in the previous example we have two valid options, and the
> algorithm chooses the ugliest one, here we have the algorithm a priori
> discarding the option that would be the best one. I think we could call
> this a bug, as there can be no doubt concerning what a user would expect.
> I'm attaching [check; double check; look again; yes, it's there!] a
> testcase showing this kind of layout problem. Trunk leaves an empty
> space between the last content line and the first footnote one, the
> float branch places two more content lines, filling the empty space, and
> the patched branch behaves the same way.
>> [snip on the other good remarks]
>> My feeling is that the Knuth algorithm can nicely handle such problems
>> already as is. It's just a matter of defining the right demerits for
>> deferred footnotes, and give a chance to too-short nodes with
>> non-deferred footnotes to be considered WRT normal nodes with deferred
>> ones.
> Demerits could not be enough: if there isn't any object with some
> stretch or shrink and the footnotes / floats do not fit exactly in the
> page but the content lines do, too-short nodes will only be considered
> when there is a restart and there isn't any deactivated node. Maybe we
> should be less restrictive on the ratio-based selection criterion.
>> I seem to remember that there was also a problem with flushing
>> floats on the last page (footnotes were unnecessarily deferred). I'd
>> have to dig deeper into that. I'll try to illustrate my ideas in a patch
>> in the next days.
> Ok, I'm looking forward to see it!
> Regards
>     Luca

Reply via email to