[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.
- vim :hardcopy equivalent, me . groff, 2024/07/21
- Re: vim :hardcopy equivalent, Robert Thorsby, 2024/07/21
- Re: vim :hardcopy equivalent, Jan Eden, 2024/07/22
- Re: vim :hardcopy equivalent, me . groff, 2024/07/24
- Re: vim :hardcopy equivalent, Dave Kemper, 2024/07/29
- Re: vim :hardcopy equivalent, G. Branden Robinson, 2024/07/30
- Re: vim :hardcopy equivalent, me . groff, 2024/07/25