Re: [Groff] Werner's Margin Notes

[Peter Schaffter]

On Sun, Jan 16, 2005, Werner LEMBERG wrote:
> 
> > I created 2 files, MN.tmac and werner.t and then ran,
> >   groff -ms werner.t > werner.ps
> 
> I suggest to add the command line option `-ww' to see all warnings.
> Then you'd probably seen the problem by yourself.
> 
> > Also, is there any "standard" support in groff for margin notes.
> > i/e, any standard macro package, which makes creation of margin
> > notes simple.
> 
> I don't think so.  Even the new `mom' macro package doesn't have
> support for margin notes, as far as I can tell -- maybe you can
> convince Peter to add this feature...

I foresee some problems with this, since I'm not sure how people
would want to use it.  I don't presently have need of margin
notes--never had--so I'd need some suggestions.

If I created a macro called MN (Margin Notes), I imagine it would
store the margins note and associated ev in a diversion, then, when
finished, would output the margin note *starting on the baseline
that was current when MN was called*.  Page overruns would be
handled by the bottom- and top-of-page traps.

i.e.,

    a line of text
    .MN
    <text of margin note>
    .MN OFF
    more lines of text

would output the first line of the first margin note on the same
baseline as "a line of text".  If the note ran long, only the
portion that fit on the page would be output, with the overflow
being output starting at the nominal first baseline of running text
on the next page.

Problem with that scenario is, what happens if users go margin note
crazy?  There'd be no way, in user space, to know if the text of one
margin note ran so long that a second margin note on the same page
might overprint the end of the first.

Which would mean that all margin notes for a given page would have
to be collected in a diversion, then output when the bottom-of-page
trap is reached.  This would remove any possibility of overprinting,
but could well result in margin notes that aren't located near the
text to which they refer.  In effect, they'd become like vertical
footnotes, except they wouldn't have any markers in the text itself
to identify them.

Then there's the problem of margins.  In the event a user didn't
set up left margin large enough to permit decent typsetting of the
margin notes, should a warning be issued?  Or should printing carry
on anyway (with ghastly results and possibly reams of wasted paper)?
And what would constitute a reasonable margin?  Seems to me some
correlation would have to be made between the type point size and
the available line length, in order to determine whether "decent"
typesetting was possible.  Not the easiest judgment call in the
world to make.

All of which is to say, if I get a better idea of how people
would use margin notes functionality, I might be able to come up
with something.  But I do need that feedback, since, as I see
presently see the issue, it strikes me as a lot of trouble for not
particularly useful results.  All suggestions welcome.

OT
--

While we're on the subject of features, there are two things I'd
like to see in groff -Tps, and I'm wondering how difficult they'd
be to implement.

One is a request, similar to .sp | , that advances from the top edge
of the page to the *baseline* on which type will sit.  groff's
present behaviour is to treat, for example,

    .sp |1i

as meaning "advance 1 inch from the top edge of the page to the top
of the tallest ascender of type at the current point size".  I'd
like to see something that advances to the baseline, not to the top
of the type.

The other thing I'd really like to see is a single request that
behaves exactly like .br, except that it doesn't advance on the
page.  IOW, a single request equivalent to

    .vs 0
    .br

which would have the effect of "carriage return/no linefeed".
Furthermore, such a request would never spring page traps.

If such a request existed (let's call it .cr),

    +-------------------------------------------------+
    | a b c d e f g                                   |
    | .cr                                             |
    |  a b c d e f g  \" Note the space in column one |
    +-------------------------------------------------+

would output

    aabbccddeeffgg 

(which should be taken as ascii-simulated overprinting).

-- 
Peter Schaffter
  Author of _The Schumann Proof_ (RendezVous Press, Canada)
  http://www.golden.net/~ptpi/theschumannproof.html