Re: [mom] Extraneous empty line that starts a new page
On 2023-04-24 21:59 -0400, Peter Schaffter wrote: > On Mon, Apr 24, 2023, Frederic Chartier wrote: > > I'm running groff 1.22.3, by the way. It's been patched but not > > since 2016 so if it's bugs I'm seeing, they're not new. > > Can you check whether you're using the latest version of mom > (2.5_c)? If not, you can get it at > > https://www.schaffter.ca/mom/mom-2.5_c.tar.gz > > The mom version that ships with 1.22.3 is quite out of date; this > may have a bearing on your problem. mom 2.5_c gives completely different results. The output now looks much more like what I was aiming for. No spurious empty paragraphs before the tables (S.E.P.B.T.). No extra blank page. No vertical space above "Second heading". And no warnings. It looks like whatever caused S.E.P.B.T. was fixed between 2.1_c and 2.5_c. Have the other problems been corrected as well or merely disturbed out of existence when the tables got shifted upwards ? Not sure, but they haven't resurfaced on the longer document I'm working on here so, for now, I suppose we can assume the former. Sorry if I made you chase dead bugs. :-/
Re: [mom] Extraneous empty line that starts a new page
Frederic -- At 2023-04-24T01:37:00+0200, Frederic Chartier wrote: > I've stumbled on another problem with -mom. There is a table at > the bottom of a page. After the table, something inserts what > behaves like a line feed and Groff warns that > > [mom]: '2023-04-24.mom', macro TE, line 61: > Insufficient room for label, caption, and/or source after > table on page 1. Omitting, but continuing to process. > 2023-04-24.mom:61: environment stack underflow > > Two things strike me as odd about these messages. First, the > table in question has no label, caption or source so why warn > about it ? Second, "environment stack underflow" sounds like > something went wrong in mom's internals. > > If anyone cares, 2023-04-24.mom is attached. With the .NEWPAGE > after the table page 2 is empty (except for the header) and > "Second heading" is pushed back to page 3. Without the .NEWPAGE, > "Second heading" is on page 2 as it should be but too low. I'm unable to reproduce either of these problems with mom 2.5_c. As posted earlier, I suspect updating your version of mom may be all that's required. -- Peter Schaffter https://www.schaffter.ca
Re: > Re: [mom] Extraneous empty line that starts a new page
At 2023-04-25T10:05:14-0400, Douglas McIlroy wrote: > > $ ./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. > > Beware of the infamous Postel principle, which has enabled many hacker > exploits and was embraced by the original definition of HTML: Be > conservative in what you write and liberal in what you accept. With > every browser having its own liberal idea, authors wrote HTML in local > cocoons, making HTMLdocuments hideously fragile. Ironically, Postel's > bad advice has been called the "robustness principle". Yes. I am particularly motified by the two examples above because they are seductively misleading of the user. groff "understands" the conventional unit abbreviations "in" and "cm", they will think. And be frustrated when "pt", or others they might imagine, don't work. I'm in the choir you're preaching to. But you probably knew that--you've seen me prattle on about how much better Ada was than C. Apart from the whole "lack of industry-reconfiguring success" thing. > In the interest of portability, I would make this a hard error, though > not necessarily one that stops groff in its tracks. We might parlay > this to a wider discussion later. I might slip this in at about the same time as I deal with https://savannah.gnu.org/bugs/?60955 Regards, Branden signature.asc Description: PGP signature
> Re: [mom] Extraneous empty line that starts a new page
> $ ./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. Beware of the infamous Postel principle, which has enabled many hacker exploits and was embraced by the original definition of HTML: Be conservative in what you write and liberal in what you accept. With every browser having its own liberal idea, authors wrote HTML in local cocoons, making HTMLdocuments hideously fragile. Ironically, Postel's bad advice has been called the "robustness principle". In the interest of portability, I would make this a hard error, though not necessarily one that stops groff in its tracks. We might parlay this to a wider discussion later. Doug
Re: [mom] Extraneous empty line that starts a new page
Hi, Branden. On Mon, Apr 24, 2023, G. Branden Robinson wrote: > > 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. I'll build/install/test 1.23.0_rc4 and report back with results. > 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. Now, this is interesting. Still running 1.23.0_rc1, I switched out the tbl executable for the one that shipped with 1.22.4. No numeric overflow, everything went through fine. It might be worth mentioning that the numeric overflow errors begin with the second table in the OP's document. The first, by itself, generates none. > > 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 It is. > For the time being I propose we back off of '-ww' usage with mom(7). > I'm not sure it is helping illuminate anything. Agreed. > Maybe passing the white-gloved barracks inspection can be an objective > for mom 2.6. ;-) Cheers. -- Peter Schaffter https://www.schaffter.ca
Re: [mom] Extraneous empty line that starts a new page
Frederick -- On Mon, Apr 24, 2023, Frederic Chartier wrote: > I'm running groff 1.22.3, by the way. It's been patched but not > since 2016 so if it's bugs I'm seeing, they're not new. Can you check whether you're using the latest version of mom (2.5_c)? If not, you can get it at https://www.schaffter.ca/mom/mom-2.5_c.tar.gz The mom version that ships with 1.22.3 is quite out of date; this may have a bearing on your problem. -- Peter Schaffter https://www.schaffter.ca
Re: [mom] Extraneous empty line that starts a new page
[self-clarification] At 2023-04-24T18:13:09-0500, G. Branden Robinson wrote: > Space management around tables is the responsibility of each macro > package. The job of tbl(1) itself is to render the table. There was > a bug in the past several versions of groff in this area, but it > involved man(7) documents, not mom(7), and the issue was too little > space _after_ a table, not too much _before_ it (also: in nroff mode > only). My use of the past tense suggests, but I did not explicitly state, that the aforementioned bug is now fixed. And it is, in the forthcoming groff 1.23.0 release. Some carnival barker _I_ am... Regards, Branden signature.asc Description: PGP signature
Re: [mom] Extraneous empty line that starts a new page
Hi Frederic, At 2023-04-24T21:56:58+0200, Frederic Chartier wrote: > Here's another tbl-related problem I've encountered, in case the two > are connected. Groff acts as if every table were preceded by an empty > paragraph. This is why there is so much vertical space between the > headings and the tables that follow them. My work-around was to put > ".LS 0" in front of every ".TS". > > I'm running groff 1.22.3, by the way. It's been patched but not > since 2016 so if it's bugs I'm seeing, they're not new. Space management around tables is the responsibility of each macro package. The job of tbl(1) itself is to render the table. There was a bug in the past several versions of groff in this area, but it involved man(7) documents, not mom(7), and the issue was too little space _after_ a table, not too much _before_ it (also: in nroff mode only). Regards, Branden signature.asc Description: PGP signature
Re: [mom] Extraneous empty line that starts a new page
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. > 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. > 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
Re: [mom] Extraneous empty line that starts a new page
On 2023-04-24 14:55 -0400, Peter Schaffter wrote: > 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. 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. tbl(1) handling at or near a page > transition presents a number of edge cases and I may not have caught > them all. Thanks for looking, Branden and Peter. Here's another tbl-related problem I've encountered, in case the two are connected. Groff acts as if every table were preceded by an empty paragraph. This is why there is so much vertical space between the headings and the tables that follow them. My work-around was to put ".LS 0" in front of every ".TS". I'm running groff 1.22.3, by the way. It's been patched but not since 2016 so if it's bugs I'm seeing, they're not new.
Re: [mom] Extraneous empty line that starts a new page
Sorry for top-quoting Branden's reply _in toto_ but it will make replying easier. On Sun, Apr 23, 2023, G. Branden Robinson wrote: > Hi Frederic, > > At 2023-04-24T01:37:00+0200, Frederic Chartier wrote: > > I've stumbled on another problem with -mom. There is a table at > > the bottom of a page. After the table, something inserts what > > behaves like a line feed and Groff warns that > > > > [mom]: '2023-04-24.mom', macro TE, line 61: > > Insufficient room for label, caption, and/or source after > > table on page 1. Omitting, but continuing to process. > > 2023-04-24.mom:61: environment stack underflow > > > > Two things strike me as odd about these messages. First, the > > table in question has no label, caption or source so why warn > > about it ? Second, "environment stack underflow" sounds like > > something went wrong in mom's internals. > > I don't have a solution for you because I'm not qualified to do mom(7) > support, but I can clarify a couple of things. > > The first diagnostic messge comes from the macro package, from mom(7) > itself. The second one, the cryptic "environment stack underflow", > comes from the formatter (GNU troff). > > I tried to dig deeper into this, but when I format this document using > groff Git HEAD, with the "-b" and "-ww" flags to sniff out as many > problems as possible, I get a _lot_ of diagnostics. > > troff: backtrace: file > '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':20283 > troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:20283: > warning: macro 'PDFBOOKMARK.NAME' not defined > troff: backtrace: file > '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':23328 > troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:23328: > warning: macro 'pdfview' not defined > troff: backtrace: > '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':4286: macro > 'PRINTSTYLE' > troff: backtrace: file 'ATTIC/frederic.mom':3 > troff:ATTIC/frederic.mom:3: warning: register '#COLLATE' not defined > > 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'. > 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. 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 The first thing to notice is that the document is 71 lines long so the reported line numbers aren't useful. 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. 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. 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. tbl(1) handling at or near a page transition presents a number of edge cases and I may not have caught them all. I'm re-attaching the OP's original document with the erroneous 'cm' corrected to 'c' for convenience. -- Peter Schafter https://www.schaffter.ca .PAPER A4 .DOCHEADER OFF .PRINTSTYLE TYPESET .L_MARGIN 2.0c .R_MARGIN 2.0c .B_MARGIN 2.0c .PT_SIZE 14 .LS 20 .FAMILY H .HEADERS .HEADER_MARGIN 2.0c .HEADER_GAP 1.5c .HEADER_LEFT "x" .HEADER_RIGHT # .PAGINATE OFF .START .HEADER .HEADING 1 "First heading" .HEADING 2 "x" .TS H ; l r. .TH x x x x .TE .HEADING 2 "x" .TS H ; l r. .TH x x x x x x .TE .HEADING 2 "x" .TS H ; l r. .TH x x x x .TE .HEADING 2 "x" .TS H ; l r. .TH x x .TE .HEADING 2 "x" .TS H ; l r. .TH x x x x x x x x x x .TE .NEWPAGE .HEADING 1 "Second heading" .HEADING 2 "x" .TS H ; l r. .TH x x x x .TE
Re: [mom] Extraneous empty line that starts a new page
Hi Frederic, At 2023-04-24T01:37:00+0200, Frederic Chartier wrote: > I've stumbled on another problem with -mom. There is a table at > the bottom of a page. After the table, something inserts what > behaves like a line feed and Groff warns that > > [mom]: '2023-04-24.mom', macro TE, line 61: > Insufficient room for label, caption, and/or source after > table on page 1. Omitting, but continuing to process. > 2023-04-24.mom:61: environment stack underflow > > Two things strike me as odd about these messages. First, the > table in question has no label, caption or source so why warn > about it ? Second, "environment stack underflow" sounds like > something went wrong in mom's internals. I don't have a solution for you because I'm not qualified to do mom(7) support, but I can clarify a couple of things. The first diagnostic messge comes from the macro package, from mom(7) itself. The second one, the cryptic "environment stack underflow", comes from the formatter (GNU troff). I tried to dig deeper into this, but when I format this document using groff Git HEAD, with the "-b" and "-ww" flags to sniff out as many problems as possible, I get a _lot_ of diagnostics. troff: backtrace: file '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':20283 troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:20283: warning: macro 'PDFBOOKMARK.NAME' not defined troff: backtrace: file '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':23328 troff:/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac:23328: warning: macro 'pdfview' not defined troff: backtrace: '/home/branden/src/GIT/groff/build/../contrib/mom/om.tmac':4286: macro 'PRINTSTYLE' troff: backtrace: file 'ATTIC/frederic.mom':3 troff:ATTIC/frederic.mom:3: warning: register '#COLLATE' not defined Something's gone badly wrong, and I'm not sure what. Possibly the document's state is invalid (mom(7) is not implemented sloppily). Maybe there is a setup macro you should be calling that you have forgotten, and mom(7) could be checking for this, scolding you, and bailing out, or taking care of the setup itself. I'm sure Peter's cluebox is much fuller than mine. Regards, Branden signature.asc Description: PGP signature
