bug-groff
[Top][All Lists]
Advanced

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

[bug #58736] [me] footnote breaks two-column output


From: Dave
Subject: [bug #58736] [me] footnote breaks two-column output
Date: Sun, 3 Jul 2022 04:43:15 -0400 (EDT)

Follow-up Comment #28, bug #58736 (project groff):

[comment #22 comment #22:]
> It is designed to output footnotes in multi-column mode at the
> bottom of the _column_, not the page.
> 
> But what to do when the document returns to single-column mode
> with a footnote pending?

The general question is more complicated than that, as you can go from
m-column output to n-column output without passing through single-column
output on the way.  That is, the below works as expected.  (Perhaps "as
expected" is too strong, since the manual is silent about whether it's
supported--maybe "as hoped"?)

.2c "" 3
Column 1.
.bc
Column 2.
.bc
Column 3.
.2c "" 4
Column 1.
.bc
Column 2.
.bc
Column 3.
.bc
Column 4.

So it's more generally a question of what happens when the number of columns
changes when a footnote is pending.

And I'm not sure there's a good general answer, since what the user might be
expected to want is fairly situational.  If it's some kind of magazine or
journal layout, where one multicolumn article ends, a full-width title
introduces the next article, then a new multicolumn article begins, emitting
the "footnotes" midpage upon encountering the .1c makes a lot of sense.  But
if the temporary multicolumn passage is for some effect within a continuous
text--maybe showing an original writing and a translation thereof side by
side, for example--footnotes in the middle of the page might look odd.

The answer is also likely to be different if you're talking about terminal
output rather than typeset output, especially if the terminal output is not
"paginated" in any meaningful sense.

And as an implementation matter, I presume footnotes are stored using roff
diversions, which store formatted text, which means they can only be stored
using the current column width, not whatever unknown future column width will
be in play at the bottom of the page.

So yeah, I agree with your statement:

> I think the problem arises from a gap in the macro package's design.

...and I'm beginning to see why this gap may have been left.

On the one hand, it might be nice to give the user some control over which of
the various schemes we've identified (and maybe some we haven't yet) is used. 
On the other, that seems like a nontrivial change to the user interface of a
little-used macro package, to handle an issue that seems to have come up
hardly at all in the 40-odd years the package has been around.

I sympathize with your reaching for the simplest solution--force a page break
whenever the number of columns changes while footnotes are pending--but this
is particularly ill suited for terminal output, where the "page length" may
have been set to thousands of lines.

I'll have to give this more thought.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58736>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

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