bugGNU troff - Bugs: bug #57538, [me] incorrect PostScript output...

 
 

bug #57538: [me] incorrect PostScript output of macro .(b

Submitted by:  Dave <barx>
Submitted on:  Sat 04 Jan 2020 08:12:45 PM UTC  
 
Category:  Macro - me Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Thu 06 Feb 2020 11:25:37 PM UTC, comment #3: 

  The symptom is caused by a higher footer in troff-mode than in the
nroff-mode.

  The footer in troff-mode is half a line bigger (6.5 v).

  The documentation ("doc/meref.ps") mentions "6v ...[nominal]" for
the register "bm".

  It is common to have a different page layout in troff from that in
nroff as the resolution is very different.

  troff is a typesetting "machine"; nroff a typewriter, line printer
"machine".

Bjarni Ingi Gislason <bjarniig>
Sun 05 Jan 2020 02:01:38 AM UTC, comment #2: 

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.

Dave <barx>
Project Member
Sat 04 Jan 2020 09:20:23 PM UTC, comment #1: 

Further discussion about this bug, though nothing conclusive, took place on the groff email list, in the thread starting at http://lists.gnu.org/archive/html/groff/2013-03/msg00012.html

Dave <barx>
Project Member
Sat 04 Jan 2020 08:12:45 PM UTC, original submission:  

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

Dave <barx>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-04 barx Summary-me macros: incorrect postscript output of macro .(b => [me] incorrect PostScript output of macro .(b
    2020-07-25 gbranden CategoryMacro - others => Macro - me

    Back to the top


    Powered by Savane 3.6