[bug #57538] -me macros: incorrect postscript output of macro .(b

[Dave]

Follow-up Comment #2, bug #57538 (project groff):

Additionally, the thread mentioned in comment #1 continued for a bit off-list
when Deri emailed me some PDF attachments he couldn't easily send to the list.
 And thanks to his work, I've been able to home in a little more on this bug.

Because as it turns out, while the bug was in groff 1.21, and is in current
groff, it has not been in every version of groff released in between.  I'm not
sure which all official releases it appears in -- it is absent in at least
1.22.2 and 1.22.3 -- but I've iterated through the various versions of
tmac/e.tmac / tmac/e.tmac-u (the file was renamed at some point) to find out
exactly where it came and went.

The bug disappeared in commit b6906269 of this file and reappeared in commit
98b028d6.  But the interesting thing about this is that these commits also
respectively introduced and then removed another bug.

As documented, all "displays" in -me (of which ".(b" is one) should have space
corresponding to the \n(bs register above and below; the test case at hand
explicitly sets this register to 0, specifying no extra space above or below
the block.  But starting with commit b6906269, this test case began emitting
an extra line above the .(b block; commit 98b028d6 fixed this.

So somehow this extra-space bug removed, or at least masked, the page-break
bug as a side effect.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57538>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/