> The common convention is that only a footnote cited in the last content
> line of the bage may be broken across pages, and no further footnote
> content will be deferred to the next page. In fact, breaking footnotes
> should be avoided if the content line citating the footnote can be put
> onto the next page withouth leaving an ugly white area below the
> content, either by distributing surplus bpd space to before/after
> block spaces or by fiddling with line heigths (or both).
Ok, thanks for your detailed answer.
I'm going to fix the implementation: at the moment, the algorithm could
decide to break a footnote and add some more content line instead.
After that, I'd like to take some time to work on my extensions, that are
exactly devised to avoid empty areas ... my wiki page is still quite
Andreas L. Delmelle wrote:
> AFAICT 'xsl-footnote-separator' is meant to be specified as the flow-name
> property on an fo:static-content, so in essence they are meant to be mostly
> the same for an entire fo:flow (~ fo:page-sequence), BUT...
> One thing I wonder about: Is it allowed to have sth like
> <fo:static-content flow-name="xsl-footnote-separator">
> <fo:retrieve-marker .../>
> In which case the content of the separator *would* be page-specific...?
I think you could be right ... the recommendation (6.11.4.
fo:retrieve-marker) states that "An fo:retrieve-marker is only permitted
as the descendant of an fo:static-content".
So, even if it is quite unlikely, we should be ready to handle the case of
a footnote separator changing from page to page.
Glen Mazza wrote:
> I don't mind the code as it is. But if you'd like we can go back to a
> two-argument constructor (just the PSLM and SC object), and then provide
> separate methods to set the Region or Block. BTW, since the only thing
> these two usages appear to have in common is that both they work with
> fo:static-content, would you rather have separate
> SideRegionLayoutManager and a FootnoteSeparatorLayoutManager? (Possibly
> having FSLM extend BlockLM?) Another possibility to think about, and
> perhaps for Andreas and others to chime in on.
The latter seems very interesting, but if it is really true that the
separator could have some retrieve-marker descendant, this is no more
possible (or not?).
Thank you all for your feedback!