Following up on an issue from last month... At 2021-05-21T19:28:17+1000, G. Branden Robinson wrote: > At 2021-05-20T16:09:59+0200, Ingo Schwarze wrote: > > Hi Branden, > > G. Branden Robinson wrote on Thu, May 20, 2021 at 01:23:18AM -0400: > > > > > commit bf4b3dde3ba442a0cf52e986d2549f1dc47f43c5 > > > Author: G. Branden Robinson <[email protected]> > > > AuthorDate: Thu May 20 11:45:10 2021 +1000 > > > > > > [mdoc]: Align header/footer spacing with man(7). > > > > > > * tmac/mdoc/doc-common-u (doc-end-macro): When continuously > > > rendering, increase page length by same amount we vertically > > > space after flushing a pending output line, for symmetry > > > with other spacing requests (and to prevent nasty surprises > > > analogous to those in Savannah #60611). > > > > > > (doc-header): Put 3 vees of space after the header in > > > continuous rendering mode, not 1 (and increase page length > > > accordingly). > > > > I very strongly object. Please revert all recent commits > > manipulating mdoc(7) vertical spacing before and after header and > > footer lines (i think there was at least one other during the last > > one or two days). > > I can't take this literally. As part of the above quoted material > there is the following. > > > > * tmac/mdoc/doc-common-u (doc-end-macro): When continuously > > > rendering, increase page length by same amount we vertically > > > space after flushing a pending output line, for symmetry > > > with other spacing requests (and to prevent nasty surprises > > > analogous to those in Savannah #60611). > > If you'll take the time to read Savannah #60611[1] I believe you will > agree that I found and fixed a rendering problem. Maybe you'll need > to do some experimentation on your own to be convinced. I sliced my > changes very finely while tracking it down and I'm as confident as I > can be without contriving an mdoc document exhibiting it--to which I > did give some consideration, before deciding that groff_mdoc(7) is > sufficiently lengthy and exhibits sufficient exercise of the mdoc(7) > feature set that I'd catch regressions in my usual process[2]. [...] > Traditional man(7) never had continuous rendering mode. As far as I > know, in the context of man(7) documents, it's groff's innovation, and > we can therefore change it. > > I have no objection to doing so; the main reason I didn't was that I > didn't want to disturb existing practice. I get the feeling you'll > tell me I respect all the wrong traditions. ;-)
I've now taken care of this. Here is a diff between the relevant macros
just prior to the commit quoted above, and now. As I hope is obvious, a
straight reversion was not appropriate.
diff --git a/tmac/mdoc/doc-common-u b/tmac/mdoc/doc-common-u
index 3d6cfb57..bd8e88c4 100644
--- a/tmac/mdoc/doc-common-u
+++ b/tmac/mdoc/doc-common-u
@@ -934,8 +934,10 @@
.de doc-header
. ev doc-env-dh
. doc-setup-page-layout
-. if !\n[cR] \
+. if !\n[cR] \{\
+. \" Re-use doc-header-space between page top and header.
. sp \n[doc-header-space]u
+. \}
. nr doc-reg-dh \w'\*[doc-caption-font]\*[doc-header-string]\f[]'
. nr doc-reg-dh1 \w'\*[doc-caption-font2]\*[doc-volume]\f[]'
. if (\n[doc-reg-dh] + \n[doc-reg-dh1] + \n[doc-reg-dh] >= \n[.lt]) \{\
@@ -955,8 +957,10 @@
. tl
\*[doc-caption-font]\*[doc-header-string]\f[]\*[doc-caption-font2]\*[doc-volume]\f[]\*[doc-caption-font]\*[doc-header-string]\f[]
. ie !\n[cR] \
. sp \n[doc-header-space]u
-. el \
+. el \{\
+. pl +1v
. sp 1v
+. \}
. ev
. ns
..
@@ -1017,14 +1021,12 @@
. \" footer. So we fudge the page length to make sure that the last
. \" page is never ejected until we want it to be.
.
-. if \n[cR] \
-. pl +3v
. fl
-.
. doc-check-depth
.
. if \n[cR] \{\
-. sp 3v
+. pl +1v
+. sp 1v
. tl
\*[doc-caption-font]\*[doc-operating-system]\f[]\*[doc-caption-font2]\*[doc-date-string]\f[]\*[doc-caption-font]\*[doc-operating-system]\f[]
. \" suppress empty lines after the footer
. pl \n[nl]u
> Before we (temporarily) depart historical matters, is it your claim that
> mdoc/BSD nroff innovated "continuous rendering mode"? I ask simply
> because I'm curious.
I remain curious about this.
Regards,
Branden
signature.asc
Description: PGP signature
