Luca Furini a écrit : > I agree that, in a sense, the "error" is in the fo file, defining a > fixed-height footnote separator that does not fit well the page; with an > heigth of 12 pt, all would be ok. In alternative, it could be defined > using a min-opt-max line height or space-*, allowing for some stretch > and shrink (not sure this would be handled correctly at the moment, but > this is not the point).
I've had a quick look, that's not handled currently. At some place in the code the space-before set on the separator is converted into a MinOptMax(opt, opt, opt). Anyway, even if defining some elastic height for the separator would certainly help improve the situation, that's not something we can expect from users. > But I don't agree with you when you say "that makes a feasible node > which is always preferred to too-short nodes". I'm not at all convinced > that it is a "feasible" break. Even if the FO recommendation says that > the footnote body could be placed in a page following the one with the > anchor, I think it should be read in a "restrictive" interpretation, > deferring a footnote only if there isn't any possible alternative. Actually I was describing the algorithm's behavior, and I agree with you that this is not at all desirable. > In this case, it is possible to place the footnote in the same page that > contains its citation, so I think that the algorithm should not be > allowed to prefer a break that defers it. Note [:-)] that the footnote > could appear after *many* pages, if there are lots of 12pt-high lines of > normal text. Hmmm, that's not wrong ;-) > In this respect, from a user perspective, footnotes and before floats > are quite different: while it's completely acceptable for a figure or a > table to be placed in a page following the text referring to it, I'm > sure most users would be quite disappointed to find out that a footnote > has been unnecessarily deferred. > > So, while I think the idea of the page fill ratio is very good for the > placement of before floats, I think footnotes should have a different > handling, a "preferential treatment" limiting deferments to the > extremely unlikely case of an unbreakable group of lines with a lot of > footnotes, a few of which does not fit in the page (or some other > extreme situations). > >> The actual problem IMO is to define the right demerits for underfull >> pages and deferred before-floats and footnotes in order to have a decent >> result (i.e., that a human would expect) in every case. > > I don't think it would be enough: the "expected" break (the one with > both footnotes on page 1) is a "short" solution and is not recorded, it > just updates lastTooShort. As long as there is not a restart (and having > just 12pt-high lines it will never happen), it doesn't have a chance to > be used. > > I think that, after all, this could be fixed just by checking some > additional condition before calling handleNode() the first time (when > footnotes and before floats are not not taken into account). Not sure it's that simple. Is a page containing only two lines of normal text with no deferred footnote more desirable than a full page with a deferred footnote? I think that might disturb the reader as well. That's why I got the idea of a minimum fill ratio. But obviously, as this is currently implemented that's not enough. I'll think more about it. Vincent
