Vincent Hennebert wrote:
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).
If I remember correctly, the separator bpd is taken from the generated
area (so there isn't any stretch or shrink) instead of the element
sequence. I think I (?) did so after a few unsuccessful tries to get the
dimension in a better way.
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.
I agree, the algorithm should be able to handle the most common situation
without any special hint.
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.
You are right, there should probably be an upper limit to the amount of
footnotes, and probably a user-configurable limit would be the ideal
solution, so that the users could set it in the document using an
extension property.
While the old code forbade pages with too few footnotes, the minimum fill
ratio avoids pages with too few content lines: we should find a way to
combine these techniques, without eliminating each possible solution! :-)
Regards
Luca
