[Top][All Lists]

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

[bug #64043] mixing formatting requests with macro calls produces differ

From: G. Branden Robinson
Subject: [bug #64043] mixing formatting requests with macro calls produces different unspecified behavior with groff than with AT&T troff
Date: Thu, 13 Apr 2023 20:33:32 -0400 (EDT)

Follow-up Comment #6, bug #64043 (project groff):

[comment #3 comment #3:]
> Attached screenshots ms-1.png and ms-2.png show vertical space of 25 pixels
vs 12 pixels - also seems significant and quite obvious to see.
> (file #54622, file #54623)

[comment #4 comment #4:]
> Also failing to see where that's mixing formatting requests with macro

That's because you're shifting the goal posts as I said.  The original
complaint "you" (anonymous) reported in comment #0 cited a mailing list
message which included the following.

Looking at page 158, in "8. Braces for Grouping", I see quite a bit of
white-space before

  "Rule: Braces can always be used to force EQN to treat something as
   a unit,"

which seems to correspond to 

e sup {i omega t}
Rule:  Braces can
be used to force 
to treat something as a unit,

in the source code. So the ".sp" clearly does affect spacing here
(after .EN).

So, are we talking about vertical space inside section 8, or vertical space
right before section 11?

I expect the specifics of your complaint to shift for as long as I care to
entertain this discussion.

> .nr PS 1v

This register assignment is ill-formed.  Vees are not a conventional unit for
expressing type size.  Points (or, in _groff_, scaled points) are.  Please see
the section "Measurements" of the _groff_ Texinfo manual.

At best, '.nr PS 1v' is nilpotent.  At worst, it has varying consequences on
terminal vs. typesetting devices that could be difficult to predict.

Omitting it and rendering the following document with _groff_ 1.22.4 and then

> .nr DD 0v
> .LP
> 1
> .NH
> 2
> .EQ
> 3
> .EN
> .NH
> 4
> .LP
> 5
> .DS
> 6
> .DE
> .NH
> 7
> .LP
> 8

I see nothing unexpected.

Vertical ("blank") space is evident nowhere except after the "1" paragraph
(prior to a section heading).

In _groff_, inter-display distance is applied after (displayed, as opposed to
inline) equations.  This is an old decision, going back to groff 1.02 (June
1991) or earlier.  Your inter-display distance is zero, so no vertical space
appears after it.

Looking at Lesk's 1979 tmac.s, I see that _groff_'s behavior is consistent
with, but more flexible than, his.  This Unix V7 ms also puts no vertical
space before (displayed) equations, but does put either .5v or 1v of space
after them, depending on a long chain of conditional tests that I haven't
bothered to trace in detail, but appear to be checking to see if the equation
was empty by various means (testing the diversion height, the output line
number, vertical drawing position in a diversion, and so forth).  _groff_
performs similar tests but indirects the vertical space amount through the
package's `DD` register, which is set to--surprise!--0.5v or 1v depending on
the type of output device.

The application of inter-display distance after equations does not appear to
be documented in _groff_, however, and I'm happy to do that.  Do you agree to
redraw the scope of this ticket to that problem?  Since it's only a doc
change, I may even be able to get it in for 1.23.0 final.


Reply to this item at:


Message sent via Savannah

reply via email to

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