Dave
2020-01-04 20:12:47 UTC
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/
<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/