[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] The future redux

From: Peter Schaffter
Subject: Re: [Groff] The future redux
Date: Sun, 9 Mar 2014 14:34:28 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Mar 08, 2014, Ted Harding wrote:
> Whichever way you try to output footnotes in the correct page, there
> is one situation which will cause problems.
> Namely, the in-text reference to the footnote is in what would (say)
> be printed as the last line but three on the page (i.e. 4th line from
> the bottom).
> Printing the footnote on the bottom line would take out four lines
> from the text at the bottom of the page. So either the footnote goes
> on the original page, and the line that refers to it gets carried to
> the next page (so now is on the wrong page); or else the referring
> line gets carried to the next page (so now the footnote is on the
> same page), but the current page is four lines short, which does
> not look good.
> The natural solution for this is to split the footnote, so that
> part of it fits on the original page and leaves room for the line
> which refers to the footnote, the remainder of the footnots being
> continued on the next page. For example, the start of the footnote
> on page A would be like
>   [1] This footnote ....
>       ....
>       .... [cont. on next page]
> and the continuation on the next page would be a footnote starting
>   [1 cont.] ....
> Does mom (or other macro packages) handle this automatically and
> correctly?

Differences in the general formatting of your example aside, mom
endeavours to handle the situation gracefully, in the manner you
describe.  Whenever invoked, FOOTNOTE checks whether there's
room for at least one line of footnote text on the current
page.  If there is, the footnote starts on the current page,
continuing on the next as required, regardless of the number of
footnotes on the current or the next page.  If there isn't, the
footnote is fully deferred.

If a fully deferred footnote is the only one on the page and a
star/dagger style of labelling is being used, it will have a
single-star label, which risks confusion if the page it's deferred
to also has footnotes; mom solves this problem by inserting a single
blank line after the deferred footnote, such that it's evident to
the reader that the first starred footnote belongs to the label
close to the bottom of the previous page, while the second belongs
to the current (new) page.

In instances where the deferred footnote is not the first on the
page (say it's the second and thus labelled with a dagger), no special
handling is required since it's evident, by convention, that a
dagger-labelled footnote at the top of footnotes text refers to the
previous page.

A complete description of mom's footnote handling is in the html docs

> I have to say that when (some time ago) I looked into this issue
> in detail, I could not think of a good way to handle it using a
> general macro.

Can't say I blame you for coming to that conclusion.  I'm still
uneasy with the level of complexity in mom's footnote handling,
despite no bug reports to date about behaviour inconsistent with the

> Just a further thought! My basic attitude to using [gt]roff is that
> you can let the built-ins do their job so long as it comes out right,
> but for the "final run" you may need to get those tweezers, leadings
> and wedges out and shift stuff around by hand!

Truth.  You do not want an application that makes good general
layout decisions but makes it difficult or impossible to fine-tune
according to taste or context.  The latter is an integral part of
the document production cycle.

To quote the mom docs rather than re-write:

 "Years of experience have convinced me that no program can ever
  replace the human eye and human input when it comes to high
  quality typesetting.  Words and punctuation on the printed page
  are too variable, too fluid, to be rendered flawlessly by any
  algorithm, no matter how clever."

Peter Schaffter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]