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
footnote_positioning_6.xml
Description: application/xml
footnote_positioning_6.patched.pdf
Description: Adobe PDF document
