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

[G. Branden Robinson]

Update of bug #63176 (project groff):

                  Status:                    None => Confirmed              
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up 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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63176>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/