Re: groff injects blank page; and program 'pnmtops' can't handle -nosetpage option; can't generate doc/gnu.eps

[G. Branden Robinson]

Hi Carlos,

I'll resequence your mail to put the issue you wanted to set aside last.

At 2023-04-22T05:26:37-0400, Carlos wrote:
> Currently running 
> 
> the called subprograms:
> 
> GNU grops (groff) version 1.22.4
> GNU troff (groff) version 1.22.4

Just to establish some common ground, this is indeed the latest release,
from December 2018.  We are working hard to try to get groff 1.23.0
out--we are currently at release candidate 4.  The forthcoming release
fixes literally hundreds of bugs and bears literally thousands of
changes.

https://lists.gnu.org/archive/html/platform-testers/2023-04/msg00004.html

You are not obliged to try out this release candidate in any way, but I
thought I'd mention it.

> and whether it's running -man or -mandoc, it injects a blank unwanted
> page in the very beginning of the document.

This does not sound like a known bug in groff 1.22.4.  But it does have
a familiar ring.

> It doesn't matter whether it's a postscript file or a pdf afterwards,
> groff inserts the blank page regardless
> 
> I'm not familiarized with groff but it seems as if a macro, in this
> particular case, .TH, that is normally in the beginning of the page,
> causes it,  or it's indirectly involved in this blank page. Doesn't
> matter. If i were to focus enough on the page and say open sesame
> it woudn't do anything. But if I were to type an .ig and two dots
> in between that pesky `.TH` macro, the blank page disappears. So in
> that sense, open sesame worked because ;) because the unwanted page
> is no longer there. The formatting of the page is gone, and that's
> more than an obvious Copernicus, but who cares, really?
> 
> The question is: what it's causing this unwanted blank page? Are
> locales somehow responsible for it? 
> 
> Now. The interesting part is that `man -T ps <manpage> ` works without
> an issue, but groff , or more precisely both -man and -mandoc don't
> and still injects the blank page

It sounds to me like someone or something has modified a macro file and
permitted a blank line to creep into it.  Your experiment with '.ig' was
a good idea, but it is not clear to me _exactly_ where you put it.
Perhaps you could email this list your an-old.tmac file.

Unfortunately, it is possible that the blank line crept into _any_ macro
file that troff reads when starting up, and there can be quite a few of
those.  Including localization macro files, but those aren't the first
place I'd look, especially in groff 1.22.4.

Here is a simple experiment you can try, and my results with it.

$ echo '.TH foobar 1 baz qux' | nroff -man | cat -n
     1  foobar(1)                   General Commands Manual                  
foobar(1)
     2
     3
     4
     5  qux                                   baz                            
foobar(1)

If your output differs, we'll want to know.

Here's a way to look for blank lines in macro files, with the results
from my system.

$ grep -l '^\s*$' /usr/share/groff/1.22.4/tmac/{*.tmac,mdoc/*}
/usr/share/groff/1.22.4/tmac/devtag.tmac
/usr/share/groff/1.22.4/tmac/hdmisc.tmac
/usr/share/groff/1.22.4/tmac/hdtbl.tmac
/usr/share/groff/1.22.4/tmac/m.tmac
/usr/share/groff/1.22.4/tmac/mse.tmac
/usr/share/groff/1.22.4/tmac/om.tmac
/usr/share/groff/1.22.4/tmac/pdf.tmac
/usr/share/groff/1.22.4/tmac/pdfmark.tmac
/usr/share/groff/1.22.4/tmac/s.tmac
/usr/share/groff/1.22.4/tmac/spdf.tmac
/usr/share/groff/1.22.4/tmac/www.tmac

These aren't necessarily a problem--as you noted, the `ig` request can
make blank lines harmless.  But because they're so troublesome, we've
arranged for groff 1.23.0 to have fewer.

$ git describe
1.23.0.rc4-83-g0dbc3f6c4
$ grep -l '^\s*$' tmac/{*.tmac,mdoc/*}
tmac/devtag.tmac
tmac/pdf.tmac
tmac/psfig.tmac
tmac/s.tmac

(Maybe we can kill the rest off for groff 1.24...)

Let us know what you find.

> First about the error `program 'pnmtops' can't handle -nosetpage
> option; can't generate doc/gnu.eps`
>  can't go past this very particular cvs compilation after
> who-knows-how-many-tries so far with this `program 'pnmtops' can't
> handle -nosetpage option; can't generate doc/gnu.eps` error
> 
> program 'pnmtops' can't handle -nosetpage option; can't generate doc/gnu.eps
> make[1]: *** [Makefile:14627: doc/gnu.eps] Error 1
> 
> But anyhow. I just wanted to compile from cvs

Wow, where did you dig up a live CVS repository of groff?

The project switched to Git at least ten years ago.

The Autoconf test for pnmtops might be a little misleading.  I notice
that the one in groff 1.22.4 doesn't `AC_REQUIRE` the
`GROFF_HTML_PROGRAMS` Autoconf test that checks for pnmtops in general.

(Let me see if groff Git HEAD still has that problem...

...no.  We (I) renamed some of the tests, but the substantive
functionality is still needed and still checked for.  An AC_REQUIRE is
now present.)

So I would make sure you have the "netpbm" package installed on your
system.  On a Debian-based one, this can be done with "apt install
netpbm".  We've had this check since 2006 or earlier, so it's really
hard to believe there's a version of netpbm still in the wild that lacks
the '-nosetpage' option flag.

> rather than from the tarball. In the end I found out I had the latest
> released version, so I gave up.
> 
> And this issue can be tackle later on really. Let's put it aside for
> now.

Regards,
Branden

signature.asc
Description: PGP signature