Re: [mom] Extraneous empty line that starts a new page

[G. Branden Robinson]

Hi Peter,

Thanks for riding to my support-department rescue.  :)

At 2023-04-24T14:55:00-0400, Peter Schaffter wrote:
> > Something's gone badly wrong, and I'm not sure what.
> 
> Indeed.
> 
> > Possibly the document's state is invalid (mom(7) is not
> > implemented sloppily).
> 
> The document is well-formed except for the erroneous use of 'cm' as
> a scaling unit instead of just 'c'.

...and even that appears to be harmless, at least in isolation.
Appending scaling units to an already-scaled value does not change its
value.

$ ./build/test-groff -Tutf8
.nr a 3c
.nr b 3cm
.tm a=\na, b=\nb
a=283, b=283

This suggests that one could get away with "3in" as well.  Yeesh.  Not
sure how I feel about that.  I think I'd prefer to have Yet Another
Warning Diagnostic for non-pristine input syntax.

But, back to the problem at hand...

> > I'm sure Peter's cluebox is much fuller than mine.
> 
> Actually, no.  First things first.  Just guessing, but the backtrace
> warnings you give, Branden, suggest you didn't process with pdfmom,
> which takes care of pdf forward references.  Not sure about this.

That's correct.  It usually doesn't occur to me to do this.  Also, we
don't have a "test-pdfmom" script so I have to do a lot of typing--I
could write a shell function--to exercise it from a build tree.

> Regardless, when I process the document with groff 1.23.0.rc1.3711-25fb
> and mom-2.5_c, passing pdfmom the -b flag (but not the -w flag), I
> receive a string of errors of the form
> 
>   troff: backtrace: '2023-04-24.mom':83: macro '3init'
>   troff: backtrace: file '2023-04-24.mom':92
>   troff:2023-04-24.mom:92: error: numeric overflow
> 
[rearranging a little here]

I have a few observations about this, one of which startled me.

1.  When I format the document with pdfmom from groff 1.23.0.rc4, but
    without '-ww', I get _no diagnostics at all_.  But the output also
    has no (text) content.

2.  When I add the '-ww' flag, I get tons of diagnostics.  They start
    like this.

$ GROFF_BIN_PATH=./build GROFF_FONT_PATH=./build/font 
GROFF_TMAC_PATH=./contrib/mom ./build/pdfmom -b -ww -z ./ATTIC/frederic.mom
troff: backtrace: file './contrib/mom/om.tmac':20283
troff:./contrib/mom/om.tmac:20283: warning: macro 'PDFBOOKMARK.NAME' not defined
troff: backtrace: file './contrib/mom/om.tmac':23328
troff:./contrib/mom/om.tmac:23328: warning: macro 'pdfview' not defined
troff: backtrace: './contrib/mom/om.tmac':4286: macro 'PRINTSTYLE'
troff: backtrace: file './ATTIC/frederic.mom':3
troff:./ATTIC/frederic.mom:3: warning: register '#COLLATE' not defined
troff: backtrace: './contrib/mom/om.tmac':4341: macro 'PRINTSTYLE'
troff: backtrace: file './ATTIC/frederic.mom':3

...which is pretty reminiscent of the ones I got _without_ pdfmom(1).

> Secondly, the macro '3init' is not used in om.tmac.  I've scoured the
> tmac directory but am unable to locate where it's defined nor where
> it's being called.

It's a macro name constructed by tbl(1).  These days, our tbl man page
says:

  roff interface
[...]
    GNU tbl internally employs register, string, macro, and diversion
    names beginning with the numeral 3.  A document to be preproccessed
    with GNU tbl should not use any such identifiers.

...but you probably don't violate this admonition.

> The first thing to notice is that the document is 71 lines long so
> the reported line numbers aren't useful.

No.  For a long time, GNU tbl had multiple bugs in its line number
handling.

[tbl] use of line continuation throws off input line counter
https://savannah.gnu.org/bugs/?62191

tbl reports incorrect line numbers in diagnostics
https://savannah.gnu.org/bugs/?60598

But I wouldn't swear to you that they're all squashed now.  They pass
the regression tests I have, which is a limited statement.

And, for full disclosure, the use of the `am` request is pretty much
guaranteed to throw off line numbers, at least in some circumstances.
Resolving that would be an interesting project.

> I've never seen this behaviour before.  It's been a while since I
> needed tbl(1) in a mom document so I'm thinking it crept in during
> one of the past year's bazillion commits.

<grimace>

> Most likely something to do with tbl(1) or with gropdf(1).  At any
> rate, I need help tracking this down.
> 
> Once we get the mysterious 3init problem solved, I can take a look
> at the OP's original problem.

Good news and bad news, which are the same news.  With groff 1.23.0.rc4,
none of the spew of diagnostics I get when using '-ww' with this
document implicates any tbl(1) macro or register names.  The scary
numeric overflow is gone, too.

The reason that's bad is that I don't have specific memory of fixing an
overflow bug in tbl.  In principle I could bisect it down...in a process
that binary searches the past year's bazillion commits.

<grimace>

> tbl(1) handling at or near a page transition presents a number of edge
> cases and I may not have caught them all.

I get most of the same diagnostics--if I use '-ww'--if I give groff an
input document consisting solely of this:

.PRINTSTYLE TYPESET

...so much of this output may be a red herring with respect to
Frederic's substantive problem of the output not appearing on the page.

> I'm re-attaching the OP's original document with the erroneous 'cm'
> corrected to 'c' for convenience.

For the time being I propose we back off of '-ww' usage with mom(7).
I'm not sure it is helping illuminate anything.

Maybe passing the white-gloved barracks inspection can be an objective
for mom 2.6.  ;-)

Regards,
Branden

signature.asc
Description: PGP signature