bugGNU roff - Bugs: bug #55081, [me] multi-column mode does not...

 
 

bug #55081: [me] multi-column mode does not work with very long page lengths

Submitter:  Dave <barx>
Submitted:  Fri 23 Nov 2018 10:44:53 PM UTC
   
 
Category:  Macro me Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 05 Oct 2022 10:51:39 PM UTC, comment #28: 

comment #21:

> [...] the management of footnote area traps, which are already
> known to have at least one other problem (the one where they
> retreat up the page across columns).


For cross-referencing, I was going to link to the ticket reporting this, but I couldn't find it.  Some further poking around turned up bug #61675, concerning the length of the footnote separator, whose comment 2 reminded me that the creeping-column bug was accidentally fixed as a side effect of that one.

Dave <barx>
Group Member
Sat 02 Jul 2022 10:47:25 AM UTC, comment #27: 

The problem originally reported had only to do with page lengths.  Branden broadened the scope (adjusting the Summary accordingly) in comment #8 to also include footnotes.  The original problem was fixed in the commit of comment #11.

I reopened the bug with comment #16, thinking that there were still problems with the fix, but it turns out these only arise when using footnotes (or low-level troff requests that -me disallows, as cited in comment #22).  Branden pointed out in comment #19 that the footnote issue is more properly under the purview of bug #58736, and reset the Summary to its original scope.

With comment #21 he closed it as Invalid "because I can't get things to break without using footnotes."  But footnotes were already excluded from this bug's scope at that point, and the original problem as reported was indeed fixed, so Fixed seems a more appropriate Status.  Updating accordingly.  Branden, feel free to overrule me if you disagree with any of this.

(Probably none of the foregoing matters, but comments elsewhere led me to believe Branden was gathering data based on closed bugs, so this update is to make sure this bug is properly "credited" as containing a legitimate fix that resolved an actual bug.)

Dave <barx>
Group Member
Mon 27 Dec 2021 06:33:50 AM UTC, comment #26: 

comment #25:

> Well, there's some wiggle room on whether it's Invalid or Fixed,
> since the initial report did show a legitimate problem that was
> fixed with a code change.


Now even more Fixed: see commit a51b2994.

Dave <barx>
Group Member
Mon 20 Dec 2021 04:09:14 AM UTC, comment #25: 

comment #24:

> Unless someone comes up with additional facts bearing on the
> use of unusual page lengths and multi-column mode without
> using footnotes or custom vertical position traps, I think
> this ticket can remain closed as invalid.


I agree.  (Well, there's some wiggle room on whether it's Invalid or Fixed, since the initial report did show a legitimate problem that was fixed with a code change.  It was its second life that went off the rails.)

> One could argue that me(7) should redefine `wh` and use a
> renamed version of it internally,


Yeah, policing the user's raw-request usage seems like an endless rabbit hole, and also disallows careful, limited use of .wh in situations where it doesn't conflict with the macro package.  I've successfully used it in -me documents to plant traps one line down from the current position, clearing them immediately after use.  ("Successfully" if one disregards bug #56499, that is, but that's not -me's fault.)

Dave <barx>
Group Member
Sun 19 Dec 2021 07:03:18 AM UTC, comment #24: 


comment #23:

> I can confirm that commit fa5fa889 solves the problem I saw in comment #14 when the document's footnotes are removed.  So the behavior of Bjarni's .wh-containing document is the only open question.


Hi Dave,

I would fully expect a `wh`-using document to run into problems.

As you note in comment #22, "[Bjarni's document] uses .wh to plant a trap, and .wh is not on -me's approved list of low-level roff requests."

In fact I reckon it is one of the most dangerous ones a me(7) document author can employ.

Unless someone comes up with additional facts bearing on the use of unusual page lengths and multi-column mode without using footnotes or custom vertical position traps, I think this ticket can remain closed as invalid.

One could argue that me(7) should redefine `wh` and use a renamed version of it internally, but I'll let that argument be made in a different ticket if it is to be raised.

G. Branden Robinson <gbranden>
Group administrator
Sat 18 Dec 2021 02:05:05 PM UTC, comment #23: 

I can confirm that commit fa5fa889 solves the problem I saw in comment #14 when the document's footnotes are removed.  So the behavior of Bjarni's .wh-containing document is the only open question.

Dave <barx>
Group Member
Sat 18 Dec 2021 11:24:01 AM UTC, comment #22: 

Bjarni's example, a corrected version of which is attached to comment #16, does not use footnotes and still fails for me.

I suppose it's debatable whether this is a valid -me document, as it uses .wh to plant a trap, and .wh is not on -me's approved list of low-level roff requests.

The results I was seeing in August (comment #14) may indeed have been confounded by footnotes, though.  I'll verify whether the committed fix (comment #11) solves my problem when footnotes are removed from the equation.

Dave <barx>
Group Member
Sat 18 Dec 2021 06:45:56 AM UTC, comment #21: 

I think our problems can be pinned on the management of footnote area traps, which are already known to have at least one other problem (the one where they retreat up the page across columns).

I can't screw up the formatting with the following attempted reproducer, even with 4 columns and five 200v pages.


$ cat EXPERIMENTS/long-page.me
.nr slimit 10000
.de XX
.if \\$1 \{\
.  nr N \\$1
.  \" Use .br and \c instead of .nf to avoid an empty page at the end.
.  br
\\nN\c
.  nr N -1
.  XX \\nN
.\}
..
.pl 200
.he '%'B'C'
.fo 'D'E'%'
.2c "" 4
.nr pv \n(.p/\n(.V \" page length in vees
.nr tv \n(tm/\n(.V \" "top margin" in vees
.nr bv \n(bm/\n(.V \" "bottom margin" in vees
.nr l \n(pv-\n(tv-\n(bv \" number of lines in text area
.nr p 5 \" number of pages desired
.XX \nl*\n($m*\np


Closing as invalid because I can't get things to break without using footnotes.

G. Branden Robinson <gbranden>
Group administrator
Wed 15 Dec 2021 03:51:09 AM UTC, comment #20: 

comment #19:

> Right now I'm thinking that the main barrier to solving this is
> the fact that me(7) does its initialization including things
> that depend on the page length (like setting up the footer trap)
> before reading even a single line of the input.


Hmm.  I write this in near-total ignorance of the implementation, but could -me hijack the .pl request and implement its own version that additionally adjusts whatever needs to be adjusted when the page length changes?

The -me documentation already prescribes a narrow window where .pl can be specified.  By rolling its own .pl, -me could even spit out a warning if the user tries to adjust the page length after this point.

Dave <barx>
Group Member
Tue 14 Dec 2021 09:28:16 PM UTC, comment #19: 

There were multiple issues reported in the original submission and trying to solve them both at once is looking like a tangle.

I propose that we restrict this ticket to the page length issue, and leave the multi-column mode/footnote interaction issue for bug #58736.

There are, moreover, multiple problems with multi-column/footnote interaction, including one not noted here.

Retitling.

Right now I'm thinking that the main barrier to solving this is the fact that me(7) does its initialization including things that depend on the page length (like setting up the footer trap) before reading even a single line of the input.  (It can't help it, that's what '-me' means.)  Other macro packages handle this by exposing command-line-settable registers to configure such things (like groff man(7)--while it doesn't expose a page length register, I've added one to it experimentally in the past with some success) or must be "initialized" with a macro call (like ms, which requires an early `LP` or `SH` call or similar).

At present, I suspect the foregoing design point accounts for the weird 159-line threshold issue I noted in comment #1.

G. Branden Robinson <gbranden>
Group administrator
Sun 12 Dec 2021 01:01:45 AM UTC, comment #18: 

original submission:

> For nroff output, it is often desirable to eliminate "page"
> breaks for text meant to be read in a pager such as "less."  The
> groff info manual gives advice on how to do this: "set the page
> length at the beginning of the document to a very large value."


Side note: bug #61453 requests a better way to achieve this.

Dave <barx>
Group Member
Sun 15 Aug 2021 06:18:27 PM UTC, comment #17: 

  To complete the fix, the macro must reach the footer trap irrespective
of how many other traps there are before it.

  Introduce a flag that confirms that the footer trap is reached.

  Test that in the bc macro.

  For example:

  In macro "@f":

  add a flag at the beginning of it; for testing purposes I used

  .do nr reached_footer 1

  Define 'bc' for example so:

.do de bc
.if \n@>2 .tm >> bc
.nr nr_traps (-1) 1
.if \n@>2 .tm -- bc nr_traps=\\n[nr_traps]
.
.nr reached_footer 0
.\" "reached_footer" is increased in macro "@f"
.while (\\n[reached_footer]==0) \{\
.  sp \\n(.tu
.  nr nr_traps \\n+[nr_traps]
.\}
.
.if \n@>2 .tm << bc number of traps before the footer trap: \\n[nr_traps]
..

  "@" is a register for diagnostic messages.

  The number '2' for register '@' might not be the right one for the
convention in "e.tmac"

Bjarni Ingi Gislason <bjarniig>
Sun 15 Aug 2021 09:17:54 AM UTC, comment #16: 

comment #15:

>  The attachment "55081.ipsum.me" contains a sample,
>  where a trap does hinder '.bc' to go to the next column.


Thanks, Bjarni.  An interesting thing about this example is that it exhibits the bug in either terminal or PostScript output,* while my original example was only valid for nroff.  And your example behaves the same with or without commit fa5fa889 applied.  So reopening this for now.

* The example does need a syntax error fixed before it works in troff mode, however:


.el \{\
.  nr place
.\}


The "place" register is not given a value in the troff branch of the .ie.  (With warnings enabled, troff warns about this.)  The value "16v" seems suitable for either nroff or troff output, so you don't really need the .ie/.el logic at all.  Attaching an updated file that has this simplification.

(file #51782)

Dave <barx>
Group Member
Sat 14 Aug 2021 11:27:56 PM UTC, comment #15: 

  My last paragraph is wrong (comment #12).

  Both suggestions stop spacing at the first trap (stated in the
explanation of request '.sp').

  The attachment "55081.ipsum.me" contains a sample,
 where a trap does hinder '.bc' to go to the next column.

  The spacing (as used in macro 'bc') must be continued after the ".bc"
to hit the footer trap.


(file #51779)

Bjarni Ingi Gislason <bjarniig>
Sat 14 Aug 2021 12:29:56 PM UTC, comment #14: 

For longer input, I see the same results with the proposed patch of comment #1 and the committed fix of comment #11.  I still need to produce an example that shows the problem (as I said back in comment #3 and still haven't gotten to yet).

If comment #12 is correct, there may also be other problems with the committed fix.  (Or they may be the same problem I'm seeing.  I haven't analyzed it yet.)  Bjarni, do you have an example of input that is mishandled due to the circumstances you describe?

Dave <barx>
Group Member
Sat 14 Aug 2021 12:17:54 PM UTC, comment #13: 

comment #8:

> the page length 10v case, but that seems to be ill-supported by me(7) generally.


Since addressed in commit 7bfaf799.

Dave <barx>
Group Member
Fri 13 Aug 2021 11:48:37 PM UTC, comment #12: 

 Answer to comment #10

 No to some, yes to some.

  The macro "bc" is there to switch to the next column or page.
 It is the footer-macro's job to decide what to do.

  So "bc" delegates that to the footer trap by triggering it.

  It does not do that by just going to the next trap,
 which can be anything!

  All traps located between "bc" in a column or page
 and the footer trap are touched,
 when the footer trap (the last trap in a column or page) is touched.

Bjarni Ingi Gislason <bjarniig>
Fri 13 Aug 2021 02:07:38 PM UTC, comment #11: 


commit fa5fa88957b2f2755f85fd357b4e892f5045d55f
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri Aug 13 08:51:51 2021 +1000

    [me]: Fix Savannah #55081.

    * tmac/e.tmac (bc): Fix problem with multiple columns on long pages.
      Space to the next page location trap, not 24 inches.  Thanks to Dave
      Kemper and Bjarni Ingi Gislason for help tracking this bug down.

    Fixes <https://savannah.gnu.org/bugs/?55081>.


G. Branden Robinson <gbranden>
Group administrator
Thu 12 Aug 2021 09:56:28 PM UTC, comment #10: 


comment #9:

>   I was wrong, the ".sp ..._ķ" "works" (if the value of 'k' is big enough), but not with the unit "u".
>
>   Branden's solution is right (comment #1).
>
>   (comment #8) Yes, touching the last trap on a page (footer trap) is the way to go.
>


Not necessarily the last trap, and there's no practical way to get that information anyway.  We space to the next trap, the distance to which is available in the .t register, and that makes sense because what if there's a float between the current location and the footnote break or page footer?  If someone says .bc, a float is pending, and it will fit in the space, the float should definitely go there.

Do you agree?

G. Branden Robinson <gbranden>
Group administrator
Thu 12 Aug 2021 09:43:13 PM UTC, comment #9: 

  I was wrong, the ".sp ..._ķ" "works" (if the value of 'k' is big enough), but not with the unit "u".

  Branden's solution is right (comment #1).

  (comment #8) Yes, touching the last trap on a page (footer trap) is the way to go.

Bjarni Ingi Gislason <bjarniig>
Thu 12 Aug 2021 08:40:37 PM UTC, comment #8: 

I appear to have a fix.

Bjarni put me on the right track.  It appears we do want to space down, but not to the _k register, but rather to the next trap.

Not only does this fix the long page length case, but also a problem extant in groff 1.22.4 me (and going back...?how far?) where footnotes wouldn't work in two-column mode.

Try this.


diff --git a/tmac/e.tmac b/tmac/e.tmac
index bba5db23..cb1dcc69 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -942,7 +942,7 @@
 ..
 .
 .de bc                 \" *** begin column
-.sp 24i
+.sp \\n(.tu
 ..
 .
 .


True, it doesn't work in the page length 10v case, but that seems to be ill-supported by me(7) generally.  Multiple macro packages have minimum requirements on page length but don't bother to validate them.  Sloppy.  :-/

G. Branden Robinson <gbranden>
Group administrator
Thu 12 Aug 2021 08:21:42 PM UTC, comment #7: 


comment #6:

> comment #5:
> > I don't think we can redefine `bc` as simply `.rt \\n(_ku`,
>
> Bjarni's proposed fix did use .sp, not .rt.


Ah--thanks, Dave.

Unfortunately, I cannot get that definition `.sp \\n(_ku` to work for ANY page length; not 158, not 159, not 66.  These all just start column 2 in column 1, with varying vertical space.

Setting the page length to 10 produces two pages with "Column 1." on the left on page 1 and "Column 2." on the right on page 2.

All measurements in vees.

G. Branden Robinson <gbranden>
Group administrator
Thu 12 Aug 2021 08:53:08 AM UTC, comment #6: 

comment #5:

> I don't think we can redefine `bc` as simply `.rt \\n(_ku`,


Bjarni's proposed fix did use .sp, not .rt.

Dave <barx>
Group Member
Thu 12 Aug 2021 06:47:27 AM UTC, comment #5: 

I don't think we can redefine `bc` as simply `.rt \\n(_ku`, because it doesn't go to the correct horizontal place.  Adding an absolute motion prefix `|` makes no difference.


# Original behavior with .pl 158v.
$ tgu -me EXPERIMENTS/55081.me | cat -s

Column 1.                       Column 2.

# Original behavior with .pl 159v.
$ tgu -me EXPERIMENTS/55081.me | cat -s

Column 1.

Column 2.

# Behavior with .pl 159v and `bc` defined as `.sp \\n(.pu+1u`.
$ tgu -me EXPERIMENTS/55081.me | cat -s

Column 1.

Column 2.

# Behavior with .pl 159v and `bc` defined as `.rt |\\n(_ku`.
$ tgu -me EXPERIMENTS/55081.me | cat -s

Column 1.  Column 2.

# Behavior with .pl 159v and `bc` defined as `.rt \\n(_ku`.
$ tgu -me EXPERIMENTS/55081.me | cat -s

Column 1.  Column 2.


G. Branden Robinson <gbranden>
Group administrator
Thu 12 Aug 2021 02:15:32 AM UTC, comment #4: 

  The unit 'u' is missing after '\\n(_k'.

Bjarni Ingi Gislason <bjarniig>
Thu 12 Aug 2021 01:44:34 AM UTC, comment #3: 

Thanks for looking into this, Branden and Bjarni!

The proposed patch in comment #1 does fix the problem in the trivial example in the original submission, but fails in more complex documents.  I'll try to produce one that's complex enough to demonstrate but no more complex than necessary.

I've not yet tried the alternate patch in comment #2.

Dave <barx>
Group Member
Tue 10 Aug 2021 01:46:28 AM UTC, comment #2: 

  Looking at an example in CSTR #54, page 32 "Muliple Column Output", a
fix in macro ".bc" (begin a column) is (could be) to use ".sp |\\n(_k"
instead of ".sp 24i".

  Register "_k"  is set with ".mk" (mark vertical place) in the header
macro (@h), the next column macro (@c), and conditionally in "@n" (new
column or page).

  A least the total number of lines produced is correct.

Bjarni Ingi Gislason <bjarniig>
Sat 07 Aug 2021 08:24:02 PM UTC, comment #1: 

I appear to have a fix for this.


diff --git a/tmac/e.tmac b/tmac/e.tmac
index f204cf6f..e0e6176a 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -942,7 +942,7 @@
 ..
 .
 .de bc                 \" *** begin column
-.sp 24i
+.sp \\n(.pu+1u
 ..
 .
 .


Something that bothers me is that me(7), with or without this patch, produces a 159-line document instead of a multiple of 66 for very simple input like in the original submission.

G. Branden Robinson <gbranden>
Group administrator
Fri 23 Nov 2018 10:44:53 PM UTC, original submission:  

I discovered this bug on groff 1.22.2, but it is also present in a groff built from the latest source in git.

For nroff output, it is often desirable to eliminate "page" breaks for text meant to be read in a pager such as "less."  The groff info manual gives advice on how to do this: "set the page length at the beginning of the document to a very large value."

However, this breaks -me's two-column macros.

.pl 158
.2c
Column 1.
.bc
Column 2.

Pipe the above into "nroff -me | grep ." and the output is as expected:

Column 1.                       Column 2.

But change the 158 to any higher number, and the columns are no longer output correctly:

Column 1.
Column 2.

This puts an unreasonable upper limit on the very large value one can specify to accommodate nroff output.

Dave <barx>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51782:  55081-2.ipsum.me added by barx (1KiB - text/x-troff-me - correction/simplification of 55081.ipsum.me)
file #51779:  55081.ipsum.me added by bjarniig (2KiB - application/x-troff-me - File for me macro package to test influnce of a trap on .bc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 20 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-02 barx StatusInvalid Fixed
        Planned ReleaseNone 1.23.0
    2021-12-18 gbranden StatusIn Progress Invalid
        Open/ClosedOpen Closed
        Planned Release1.23.0 None
    2021-12-14 gbranden Summary[me] two-column output does not work with footnotes or very long page lengths [me] multi-column mode does not work with very long page lengths
    2021-08-23 gbranden StatusFixed In Progress
    2021-08-15 barx Attached File- Added 55081-2.ipsum.me, #51782
        Open/ClosedClosed Open
    2021-08-14 bjarniig Attached File- Added 55081.ipsum.me, #51779
    2021-08-13 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2021-08-12 gbranden StatusNeed Info In Progress
        Summary[me] two-column output does not work with very long page lengths [me] two-column output does not work with footnotes or very long page lengths
    2021-08-12 gbranden StatusIn Progress Need Info
    2021-08-07 gbranden StatusNone In Progress
        Assigned toNone gbranden
    2021-06-04 barx Summaryme: two-column output does not work with very long page lengths [me] two-column output does not work with very long page lengths
    2020-07-25 gbranden CategoryMacro - others/general Macro me

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code