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! :-)


Reply via email to