Re: Footnotes in the float branch

[Vincent Hennebert <vi...@anyware-tech.com>]

Hi,

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.

Cheers,
Vincent

[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