groff
[Top][All Lists]
Advanced

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

Re: vim :hardcopy equivalent


From: Tadziu Hoffmann
Subject: Re: vim :hardcopy equivalent
Date: Thu, 25 Jul 2024 12:46:29 +0200
User-agent: Mutt/1.11.4 (2019-03-13)


> I will defend my formulation.  `sp` _does_ position the
> text baseline, period.

I concur.  It positions every part of the line.
I simply did not want anyone to get the impression that
".sp |3c" would put the _baseline_ at 3 cm from the top.

Also, in this case the baseline will only _normally_
be put at 3 cm + 1 vee.  If the line is overly tall
(i.e., extra line-space has been requested with \x),
then the baseline will be automatically shifted
downward by the corresponding amount.

(This is in contrast to Postscript or PDF, where a moveto
_does_ position the baseline for any text to be output,
regardless of the height of the text.)

> Where I, and apparently sometimes others, usually screw this
> up is when computing distances from the page _bottom_.

This unfortunately stems from the way traps are implemented
in troff.  The Troff User's Manual says

  The macro associated with a page trap is automatically
  invoked when a line of text is output whose vertical size
  reaches or sweeps past the trap position.

so that when you say ".wh -3c FT", when the FT macro is
invoked, the output (usually) has already intruded into the
margin of 3 cm and you can't do anything about it anymore.

I don't know whether it is possible (or desirable) to
modify the behavior so that the macro is invoked _before_
the line sweeping past the trap position is output, because
then the invoked macro needs a mechanism to deal with the
finished-but-not-yet-output line in addition to the usual
partially collected line.

My approach normally is to put the trap at -(margin+1v-1u)
and just hope that no over-tall line will be output as the
last line.





reply via email to

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