bugGNU troff - Bugs: bug #58736, -me macros: footnote breaks...

 
 

bug #58736: -me macros: footnote breaks two-column output

Submitted by:  Dave <barx>
Submitted on:  Wed 08 Jul 2020 05:40:28 PM UTC  
 
Category:  Macro - me Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Confirmed
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.

 

( Jump to the original submission)

Fri 18 Sep 2020 06:22:55 PM UTC, comment #7: 

comment #3:

> If there's a repository of these versions of the -me package
> as they existed before forking, I can't find it.


Following Branden's advice, I posted a query (http://minnie.tuhs.org/pipermail/tuhs/2020-September/022175.html) to TUHS and got an almost immediate reply with a URL (http://svnweb.freebsd.org/csrg/share/me/tmac.orig_me?view=log) to a repository of -me versions 1.1 to 2.37.  (There is also a "version 8.1," but it is identical to 2.37 other than a couple comments in the header.)

Version 2.31, the basis for groff's fork, can be found at http://svnweb.freebsd.org/csrg/share/me/tmac.orig_me?revision=34394.  The earliest recorded groff version of this file (http://git.savannah.gnu.org/cgit/groff.git/tree/macros/tmac.e?id=351da0dcdf702cf243d26ffa998961bce2aa8653) has substantial changes from this v2.31.  (This may be of academic interest, but is probably not relevant to this bug, since comment #3 suggests the bug is in historical -me code as far back as v2.14.)

Dave <barx>
Project Member
Mon 20 Jul 2020 10:40:37 AM UTC, comment #6: 

Replying to myself:

comment #5:

> Savannah unfortunately requires -me bugs be categorized under
> "Macro - others," so it's hard to tell how many are filed here.
> I've opened at least eight


I realize my prolific bug-opening is skewing these results, but for comparison, currently mm has 8 open bugs, ms 4, man 7, mdoc 6, and mom 1.  By those numbers, adding a specific -me category to savannah seems justified.  -me is also the only full-service macro package lacking its own category.

> ones like this one and bug #58447, where merely describing how
> to trigger them requires an essay.


Perhaps a better thing for the -me documentation to include than complete descriptions of these bugs is links to the savannah bug reports still open at the time of the release.

Dave <barx>
Project Member
Sun 19 Jul 2020 03:50:18 PM UTC, comment #5: 

"Soon" is not among my expectations when opening groff bugs (I've opened bugs that have garnered no response for years), especially ones in macro packages that are essentially abandonware.

My intent is to put bugs where they can be prioritized and addressed when it makes sense.  Something like bug #57616, tripped in core groff just from using certain words in running text in the wrong place, should have higher priority than this one tripped by a particular combination of macros in a little-used macro package.  But the two require different areas of expertise to debug, so it's not that straightforward.

Of course, the expertise gap in -me applies to all (known and yet-to-be-discovered) -me bugs.

Savannah unfortunately requires -me bugs be categorized under "Macro - others," so it's hard to tell how many are filed here.  I've opened at least eight, with bug #58447 having the most severe result, though probably also being among the least likely to be encountered.  I try to always put "me" at the start of the summary line, though I see I've been inconsistent about using "me:", "me macros:", and "-me macros:", and forgot it altogether at least once.

> Eric Allman occasionally speaks up on the TUHS mailing list, but he may
> consider himself retired--perhaps LONG retired--from maintaining me(7).


Yeah, if someone asked me to debug code I hadn't looked at in over 30 years, my first thought would be that a person who's never seen the code before and I would be starting in about the same place.  But I don't see any down side to asking.

And, true, aside from Eric, there may not be a good candidate for troubleshooting -me problems.  I find the -me code impenetrable.  A few email-list regulars (Tadziu, Ingo, Ralph) could probably figure them out if they had the time and motivation.  George Helffrich seems to have some expertise, in that he submitted a patch for -me bug #57638--albeit a bug he introduced three years earlier, which speaks to the danger of not having regression tests.

Still, without downplaying this danger, on the other hand I'd point out:

  • While we don't have a sizeable -me corpus like we do with -man, the four doc/*.me documents in groff's source tree should catch any blatant problems.
  • Given the age of the original macro set and the software-development methodology widely used at the time, the original development probably included limited or no regression testing, which could be responsible for the existence of many of these current bugs.  So continuing to develop without this safety net, fixing known bugs with the potential of inserting new ones as a side effect, doesn't strike me as a step backwards.
  • In fact I'd hazard that modern revision control will make any regressions discovered in the future easier to pinpoint (as I did in 57638); it's bugs in the historical -me code that are the least tractable.

But until someone volunteers to take on these risks and challenges, perhaps documenting all these bugs is best--though even that isn't easy for ones like this one and bug #58447, where merely describing how to trigger them requires an essay.  And it's tricky with ones like bug #55060 and bug #58682, where the very problem is a discrepancy between documentation and functionality with it being unclear which should be considered correct.

Dave <barx>
Project Member
Sat 18 Jul 2020 11:14:40 PM UTC, comment #4: 

Thanks for doing the research on this, Dave.

Hacking full-service macro packages like ms, mm, and me without any test suite for them, or even a corpus of example documents we can regression-test with (like man) fills with dread, and little hope we can resolve this soon.

Think this might be worth documenting in a "Bugs" (sub)section of groff_me(7)?  Maybe in meintro.me and meref.me as well.  That wouldn't enable us to close this bug, but it would serve as warning to interested users and might get a little more light thrown on the issue.

Eric Allman occasionally speaks up on the TUHS mailing list, but he may consider himself retired--perhaps LONG retired--from maintaining me(7).

Thoughts?

G. Branden Robinson <gbranden>
Project Administrator
Sat 18 Jul 2020 07:35:06 PM UTC, comment #3: 

The footnoted input file produces the same incorrect PostScript output in Heirloom troff, and the unfootnoted one produces the same correct PostScript output.  (Heirloom nroff output from both input files is pretty hopelessly broken.)

According to the header blocks of the respective files, groff's -me macros are forked from version 2.31 of Eric Allman's original set, and Heirloom's from version 2.14.  If there's a repository of these versions of the -me package as they existed before forking, I can't find it.

Dave <barx>
Project Member
Sat 18 Jul 2020 04:04:50 AM UTC, comment #2: 

I guess a reasonable next step is to find out if the me macros misbehave similarly elsewhere, or if this problem arose due to groff (either our fork of me(7) or something within the typesetting logic itself).

G. Branden Robinson <gbranden>
Project Administrator
Fri 17 Jul 2020 03:02:30 AM UTC, comment #1: 

Can confirm this.

G. Branden Robinson <gbranden>
Project Administrator
Wed 08 Jul 2020 05:40:28 PM UTC, original submission:  

This bug shows up in both PostScript and terminal output.  The example below uses nroff because that's easier to show in a bug report.  It happens on a recent groff build from git and in official groff release 1.22.3.

This input file:

A little introductory text.
.2c
This text appears in the first column of two-column output.
.bc
This text appears in the second column of two-column output.
.1c
Single-column output resumes.

when run with "nroff -me", produces:

A little introductory text.
This  text  appears  in  the    This  text  appears  in  the
first column  of  two-column    second column of  two-column
output.                         output.
Single-column output resumes.

(plus a lot of blank lines filling out the "page").  Now change the first line of the input file to these four lines:

A little introductory text.*
.(f
*A footnote.
.)f

Now, the line "Single-column output resumes," rather than appearing below the two columns as it should, is pushed to the bottom of the page, below the footnote.  It looks basically like this (though I've greatly reduced the number of blank lines):

A little introductory text.*
This  text  appears  in  the    This  text  appears  in  the
first column  of  two-column    second column of  two-column
output.                         output.











____________________
   *A footnote.
Single-column output resumes.

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 (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
    2020-07-25 gbranden CategoryMacro - others => Macro - me
    2020-07-17 gbranden StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5