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

[Dave]

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

                 Summary: -me macros: incorrect postscript output of macro .(b
                 Project: GNU troff
            Submitted by: barx
            Submitted on: Sat 04 Jan 2020 02:12:45 PM CST
                Category: Macro - others
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This bug has existed at least as far back as groff version 1.21, and continues
to exist in a groff built from recent git code (GNU groff version
1.22.4.74-b400-dirty).  It was originally reported in
http://lists.gnu.org/archive/html/bug-groff/2012-12/msg00011.html.  The code
below assumes a paper size of "letter" (groff's default in the file
/usr/share/groff/current/font/devps/DESC).

In the -me reference manual, the description for .(b says:

   If the block will not fit on the current page a new page
   is begun, unless that would leave more than \n(bt [0]
   white space at the bottom of the text.  If \n(bt is
   zero, the threshold feature is turned off.

This is not what happens in the edge case, however.  Consider:

------------------------------
.mso me.tmac     \" -me macros
.nr bs 0         \" no extra space before or after blocks
.nf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
.(b
forty-six
forty-seven
forty-eight
forty-nine
fifty
fifty-one
fifty-two
.)b
53
54
55
56
57
58
59
60
------------------------------

With either -Tps or -Tascii, on the first page this outputs lines 1 to 45,
then the seven-line block, then one more line, 53, before the page break. 
This tells us that the block would fit exactly at the bottom of the page, if
there were one more line above it (which would take the place of line 53
below).

So add one line somewhere above the .(b.

Now, -Tascii output does what's expected, putting line "fifty-two" at the
bottom of the first page, and 53 at the top of the second.  But -Tps output
puts the entire block on the second page, even though there is room for it on
the first page.

An easy way to tell where the page break falls in -Tps output without having
to generate and display a PostScript file is (using GNU's grep):

groff -Tps -a [test-file] | fgrep -C3 page




    _______________________________________________________

Reply to this item at:

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

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