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
