> I didn't understand how your code will work. The > p...@footer trap performs a move to a position spec- > ified by an absolute distance, while you only pro- > pose to change the line at which the trap is trig- > gered. This will not change the way it prints the > footnotes, because it uses absolute addressing > inside.
If you enable the debugging output in p...@set-new-trap, you'll see that in this particular example pg*foot-trap is made up of pg*footer-size (the exact height of the footer) and ft*note-size (the exact height of the footnotes). Thus, if you space absolutely to \\n[pg*foot-trap]u+1v before outputting the footnotes, these will intrude 1v into the bottom margin. That's why the "+1v" is wrong. So p...@set-new-trap contains the complete reserved height at the page bottom which the running text must not step into. Since it's possible that the line that triggers the trap can overstep the trap position by almost up to 1v, we have to set the trap position accordingly almost 1v higher, except in nroff, where trap positions are reached exactly. (It's preferable to have a little extra space between the last line and the footnotes than too little.) > .am p...@set-new-trap > . if n \{\ > . if \\n[ft*note-size]>0 .nr pg*foot-trap -1v > . \} > .. I think that leaves you with more space before the footnotes than necessary in nroff (but the bottom margin is okay), but in troff you still have the problem that the footnotes get printed 1v into the bottom margin.