bugGNU troff - Bugs: bug #56499, adjacent trap behavior...

 
 

bug #56499: adjacent trap behavior undocumented and probably undesirable

Submitted by:  Dave <barx>
Submitted on:  Sat 15 Jun 2019 10:54:01 AM UTC  
 
Category:  Core 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.

 

Sat 15 Jun 2019 10:54:01 AM UTC, original submission:  

$ groff -a << EOF
.de trap1
.tm trap 1
..
.de trap2
.tm trap 2
..
.de trap3
.tm trap 3
..
.de trap4
.tm trap 4
..
.de trap5
.tm trap 5
..
.de trap6
.tm trap 6
..
.wh 2.1i trap1
.wh 2.2i trap2
.wh 2.3i trap3
.wh 2.4i trap4
.wh 2.5i trap5
.wh 2.6i trap6
.nf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
EOF

The above command produces the following (a mix of stdout and stderr):

1
2
3
4
5
6
7
8
9
10
11
12
13
trap 1
14
trap 2
15
trap 4
16
trap 6
17
18
19
20

In a response on the email list (http://lists.gnu.org/archive/html/groff/2018-06/msg00013.html, which also addresses an unrelated issue), Werner writes, "[W]hile your first trap is active, it moves down one line, which passes some traps without triggering them."  But this behavior is not only undocumented, but seemingly unwarranted: Nothing in these traps should cause vertical movement.

Neither groff nor CSTR 54 (as Ralph points out in http://lists.gnu.org/archive/html/groff/2018-06/msg00017.html) documents this behavior.  But the behavior is not limited to the GNU troff implementation; Heirloom (http://lists.gnu.org/archive/html/groff/2018-10/msg00008.html) and Plan 9 (http://lists.gnu.org/archive/html/groff/2018-10/msg00012.html) troffs also exhibit a version of the bug.  However, Heirloom's results are different from groff's, implying that groff is not precisely reproducing historical behavior.  And there seems to be no rationale for the behavior anyway.

Furthermore, it inhibits useful functionality.  One of the above links describes a use case (for PostScript output) that the current behavior hinders: "I [was] trying to place a trap that gets triggered at the end of the current output line (that is, the next time the output's vertical position is advanced).  I did this by placing the trap a single basic unit below the current vertical position, which works in the general case.  However, if the output line in question happens to be the last line of the page, this new trap causes groff to skip the generic end-of-page trap, even though it's not overwriting that trap's page position."

Dave <barx>

 

(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 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.

     

     

     

    No changes have been made to this item

    Back to the top


    Powered by Savane 3.5