bugGNU troff - Bugs: bug #63176, [me] After column-count changes,...

 
 

bug #63176: [me] After column-count changes, -me might place running text on page below footnote

Submitter:  Dave <barx>
Submitted:  Fri 07 Oct 2022 09:17:48 AM UTC
 
Category:  Macro me Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Need Info
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       No canned response available

 

( Jump to the original submission )

Sat 15 Oct 2022 01:46:57 PM UTC, comment #7: 

comment #5:

> comment #4:
> > This seems tricky enough that I'm inclined to simply add
> > another diagnostic message: if there are pending footnotes
> > when the number of columns is changes, yell about it.
>
> There already is an error message, but--as it's not terribly illuminating of the problem--something more accurate can't hurt.


The diagnostic I have in mind is thrown from different places, so it's distinguishable.  But it may help the user track down the issue and decide if it's something they care about nonetheless.

Here's a proposed patch.

diff --git a/tmac/e.tmac b/tmac/e.tmac
index f00711577..88f966fc8 100644
--- a/tmac/e.tmac
+++ b/tmac/e.tmac
@@ -969,6 +969,7 @@
 .
 .
 .de 2c                 \" *** double columned output
+.do if d |f .do @err changing columnation with footnote pending
 .br
 .if \\n($m>1 \
 .      1c\"                            \" revert to 1c if already 2c
@@ -986,6 +987,7 @@
 ..
 .
 .de 1c                 \" *** single columned output
+.do if d |f .do @err changing columnation with footnote pending
 .br
 .nr $c 1
 .nr $m 1

And here's the output when I run "the old switcheroo" in its 4 configurations.

$ tgu -me EXPERIMENTS/the-old-switcheroo.me -z
e.tmac:EXPERIMENTS/the-old-switcheroo.me:8: changing columnation with footnote pending
e.tmac:EXPERIMENTS/the-old-switcheroo.me:28: writing 2-column footnote in 1-column layout
$ tgu -rB1 -me EXPERIMENTS/the-old-switcheroo.me -z
e.tmac:EXPERIMENTS/the-old-switcheroo.me:8: changing columnation with footnote pending
e.tmac:EXPERIMENTS/the-old-switcheroo.me:28: writing 2-column footnote in 1-column layout
$ tgu -rA1 -me EXPERIMENTS/the-old-switcheroo.me -z
e.tmac:EXPERIMENTS/the-old-switcheroo.me:8: changing columnation with footnote pending
e.tmac:EXPERIMENTS/the-old-switcheroo.me:33: changing columnation with footnote pending
$ tgu -rA1 -rB1 -me EXPERIMENTS/the-old-switcheroo.me -z
e.tmac:EXPERIMENTS/the-old-switcheroo.me:8: changing columnation with footnote pending
e.tmac:EXPERIMENTS/the-old-switcheroo.me:33: changing columnation with footnote pending

These new diagnostics get thrown at different points in the input, which I want to argue will help the document author locate the spots that matter.

What do you think of these?

Hypothetically, if we have a register that means "I want footnote in 1 column at the page foot no matter how many columns are otherwise in the running text", that would suppress the diagnostic in the `1c` macro.  But 2 conditions would need to attach: (a) this is the desired behavior, and (b) we're switching to 1c mode because we're outputting footnotes.  The latter is an additional bit of internal state that would need to be maintained.

> Sure, at this point I expect any substantive change to be 1.24 at the earliest, and maybe later, since there are certainly higher priority bugs out there.  I've retooled my own macros to sidestep this issue, so I have no personal stake in this being fixed; just want to get it documented.


Fingers crossed!

G. Branden Robinson <gbranden>
Project Administrator
Sat 15 Oct 2022 01:31:39 PM UTC, comment #6: 

I have a new exhibit that may be fodder for regression tests later.

I'll inline and attach (assuming I remember the latter).

I've en-knobbed two changes to the input text with registers A and B.  Setting register A reduces the amount of text emitted in 2-column mode and register B adds a paragraph break when returning to 1-column mode.  This gives us four cases.

1.  A and B unset.  Throws one of the new diagnostics.  Diagnostic correct as far as it goes, but looks fine.  We might want to consider some means of explicitly supporting single-column footnotes at the foot of a multi-column page (a register, probably).  The technology appears to already be present.

2. A set, B unset.  No diagnostic.  Column not long enough to break.  Things look okay.  Should also be a supported scenario.

3. A unset, B set.  We get the diagnostic, but again things look okay for the same reason as 1.  This time the column has more text so there is a column break.  But the return to single-column mode appears to not return until the next page.  Knowing the package internals somewhat, it would seem we really do return to single-column mode before the end of the page--to write the footnote.  Also a scenario we might want to support.

4. A set, B set. No extra text, no diagnostic.  There is a paragraph break when switching back to 1-column mode, and this happens on the same page.  This looks okay as well.

.lp
We're going to add a footnote
.(f
a footnote long enough to tell how many columns it spans
.)f
and change the number of columns on the page before the foot of the page
is reached.
.2c
Sed ut perspiciatis, unde omnis iste natus error sit voluptatem
accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab
illo inventore veritatis et quasi architecto beatae vitae dicta sunt,
explicabo.  Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur
aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione
voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum,
quia dolor sit amet consectetur adipiscivelit, sed quia non-numquam eius
modi tempora incidunt, ut labore et dolore magnam aliquam quaerat
voluptatem.  Ut enim ad minima veniam, quis nostrum exercitationem ullam
corporis suscipitlaboriosam, nisi ut aliquid ex ea commodi consequatur?
Quis autem vel eum iure reprehenderit, qui inea voluptate velit esse,
quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo
voluptas nulla pariatur?  At vero eos et accusamus et iusto odio
dignissimos ducimus, qui blanditiis praesentium voluptatum deleniti
atque corrupti, quos dolores et quas molestias excepturi sint, obcaecati
cupiditate non-provident, similique sunt in culpa, qui officia deserunt
mollitia animi, id est laborum et dolorum fuga.
.if !r A \{\
Et harum quidem rerum
facilis est et expedita distinctio.  Nam libero tempore, cum soluta
nobis est eligendi optio, cumque nihil impedit, quo minus id, quod
maxime placeat, facere possimus, omnis voluptas assumenda est, omnis
dolor repellendus.
.\}
.1c
.if r B .lp
Back to one column and done.

(file #53859)

G. Branden Robinson <gbranden>
Project Administrator
Sat 15 Oct 2022 04:57:23 AM UTC, comment #5: 

comment #4:

> This seems tricky enough that I'm inclined to simply add
> another diagnostic message: if there are pending footnotes
> when the number of columns is changes, yell about it.


There already is an error message, but--as it's not terribly illuminating of the problem--something more accurate can't hurt.

> I think I might have pitched this idea before.


Quite possibly.  Bug #58736 is long and my eyes tend to glaze over if I try to reread through it all.  (And I even wrote a good chunk of its verbiage.)

> I don't think it would resolve this issue, but it seems like
> footnote support in me(7) is going to require some serious
> attention to surmount the problems you've raised, which kicks
> this into 1.24 territory.


Sure, at this point I expect any substantive change to be 1.24 at the earliest, and maybe later, since there are certainly higher priority bugs out there.  I've retooled my own macros to sidestep this issue, so I have no personal stake in this being fixed; just want to get it documented.

Dave <barx>
Project Member
Fri 14 Oct 2022 11:30:05 AM UTC, comment #4: 

Hi Dave,

This seems tricky enough that I'm inclined to simply add another diagnostic message: if there are pending footnotes when the number of columns is changes, yell about it.

I think I might have pitched this idea before.

What do you think?

I don't think it would resolve this issue, but it seems like footnote support in me(7) is going to require some serious attention to surmount the problems you've raised, which kicks this into 1.24 territory.

G. Branden Robinson <gbranden>
Project Administrator
Fri 14 Oct 2022 12:41:07 AM UTC, comment #3: 

comment #2:

> Vertical motion does produce text baselines.


This statement is wrong.  `sp` does not advance the text high-water mark.  A break with `br` does, even you don't subsequently format any text on the new line.

I can't rationalize that.

But it's beside the point for the time being.

As we might have guessed, the problem seems to be that spacing to the bottom of the page (by beginning a new column) springs a footnote-related trap.

$ cat EXPERIMENTS/bad-footnote.me
.fo ''%''
.tm A: .h=\n(.h
Some text in one column.
.tm B: .h=\n(.h
.(f
A footnote.
.)f
.tm C: .h=\n(.h
.2c
First column.
.tm D: .h=\n(.h
.bc
.tm E: .h=\n(.h
Second column.
.tm F: .h=\n(.h
.1c
.tm G: .h=\n(.h
Back to one-column text.
.tm H: .h=\n(.h
$ ./build/test-groff -Tutf8 -b -ww -me -r@2 EXPERIMENTS/bad-footnote.me | cat -s
A: .h=0
>> @h %=1 ?a=0 ?b=0 ?w=0
B: .h=0
C: .h=0
D: .h=320
>> @f %=1 nl=2240 ?a=0 ?b=0 ?f=1
e.tmac:EXPERIMENTS/bad-footnote.me:12: writing 2-column footnote in 1-column layout
E: .h=2320
F: .h=2320
G: .h=2320
H: .h=2320
>> @z, .z= ?a=0
<< @z
>> @f %=1 nl=2400 ?a=0 ?b=0 ?f=0

Some text in one column.
First column.                   Second column.

____________________
   A footnote.
Back to one‐column text.

                              1

Still investigating.

G. Branden Robinson <gbranden>
Project Administrator
Thu 13 Oct 2022 11:35:53 PM UTC, comment #2: 

Hi Dave,

Here's the implementation of `1c`.  It doesn't actually do much.

.de 1c                  \" *** single columned output
.br
.nr $c 1
.nr $m 1
.ll \\n(_Lu\"                   return to normal output
.sp |\\n(.hu
.@O \\n(_ou
..

`@O` is just the `po` request renamed.

So, annotated, this macro:

1. Breaks the output line.
2. Sets both the column number and column count to 1.
3. Sets the line length to the cached value for single-column layout.
4. Vertically spaces down to the "high-water mark" for the page.  The high-water mark is defined in CSTR #54 as the "lowest place" on the current page.  This wording is ambiguous.
5. Sets the page offset to the cached value for single-column layout.

Immediately I became suspicious of that .h register.  Some instrumentation of your reproducer made me more suspicious still.

$ tgu -me EXPERIMENTS/bad-footnote.me -z
A: .h=0
B: .h=0
C: .h=0
D: .h=320
e.tmac:EXPERIMENTS/bad-footnote.me:12: writing 2-column footnote in 1-column layout
E: .h=2320
F: .h=2320
G: .h=2320
H: .h=2320

That leap from 320 to 2320 occurred when the `bc` macro was called.

It would therefore appear that our Texinfo manual is wrong.

 -- Register: \n[.h]
     The read-only register '.h' stores the "high-water mark" on the
     current page or in the current diversion.  It corresponds to the
     text baseline of the lowest line on the page.(1)  (*note
     Diversions-Footnote-1::)

          .tm .h==\n[.h], nl==\n[nl]
              => .h==0, nl==-1
          This is a test.
          .br
          .sp 2
          .tm .h==\n[.h], nl==\n[nl]
              => .h==40, nl==120

     As implied by the example, vertical motion does not produce text
     baselines and thus does not increase the value interpolated by
     '\n[.h]'.

Vertical motion does produce text baselines.  I will have to investigate the discrepancy between `.h` and `nl` in the foregoing example from our Texinfo manual.

But first I want to see what other troffs do, both with that example and your reproducer.  You can see that there is wiggle room in that CSTR #54 definition, and perhaps enough to form a noose into which we can fit our necks.

G. Branden Robinson <gbranden>
Project Administrator
Thu 13 Oct 2022 10:03:48 PM UTC, comment #1: 

original submission:

> I feel certain I've already posted an example that exhibits this problem,


Ha, yes, back in the original submission of bug #58736, which is what I was testing when I (accidentally re)created this test case.

The concerns as articulated over the subsequent 39 comments of 58736 were addressed by adding warnings in various situations beyond -me's ability to handle (because -me cannot guess what layout the user might want with some multicolumn/footnote combinations).  Warning of such situations is valid.

This is not one of those situations: the footnote is generated in single-column mode, and then later (should be) output in single-column mode on the same page.  There is no ambiguity here about what ought to be done.

The first problem seems to be that the .1c macro is unnecessarily springing the end-of-page trap: plenty of room is left on the page for the next line of running text.  (Omit the "| cat -s" from the sample command to see this more clearly.)  Were the layout as expected, the footnote, generated in one-column mode, would have later been output also in one-column mode, requiring no warning, so the warning is presumably a side effect of the layout problem.  (And, incidentally, its wording seems backwards: the footnote is associated with one-column text, but the layout in which it is output is two columns.)

The second problem (the one reported in the Summary of this bug) is that after the footnote is output, more running text is placed on the page below it.  This might technically be a separate bug, but it seems like it can only happen after the first bug is triggered, so squashing that one might be sufficient to resolve this.

Dave <barx>
Project Member
Fri 07 Oct 2022 09:17:48 AM UTC, original submission:  

I open this bug report with a strong sense of déjà vu: I feel certain I've already posted an example that exhibits this problem, but I've trawled savannah's -me bugs (open and closed) and cannot find it.

In this example, the .fo line is unnecessary to trigger the bug; the presence of the footer only makes the problem easier to see in nroff mode, where page boundaries are otherwise fuzzy.  The problem is obvious in typeset output whether the footer is present or not.

$ cat bad-footnote.me
.fo ''%''
Some text in one column.
.(f
A footnote.
.)f
.2c
First column.
.bc
Second column.
.1c
Back to one-column text.
$ nroff -ww -me bad-footnote.me | cat -s

Some text in one column.
First column.                   Second column.

____________________
   A footnote.
Back to one-column text.

                              1

The output is the same in 1.22.4 and in the latest -me code, but post-commit 4eeba76c -me also emits a warning:

e.tmac:bad-footnote.me:8: writing 2-column footnote in 1-column layout

Dave <barx>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #53859:  the-old-switcheroo.me added by gbranden (2KiB - text/x-troff-me)

 

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)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-15 gbranden Attached File- Added the-old-switcheroo.me, #53859
    2022-10-14 gbranden StatusConfirmed Need Info
    2022-10-13 gbranden StatusNone Confirmed
        Assigned toNone gbranden

    Back to the top

    Powered by Savane 3.9