Re: groff injects blank page

[Carlos]

On Mon, Apr 24, 2023 at 12:44:38AM -0500, G. Branden Robinson wrote:
> Hi Carlos,
> 
> At 2023-04-23T11:38:39-0400, Carlos wrote:
> > On Sat, Apr 22, 2023 at 04:33:52PM -0500, G. Branden Robinson wrote:
> > > At 2023-04-22T16:46:00-0400, Carlos wrote:
> > > > Sure. But no one's sure of the cause of the blank page.
> > > >
> > > > If you had to guess, what would it be?
> > >
> > > At present my guess is a loose blank line in your
> > > /etc/groff/man.local.
> >
> > Tsk tsk tsk. Branden Branden.
> >
> > Did you say open sesame. In spanish ‹Ábrete sésamo›? It takes some
> > effort but it works ;)
> >
> > This is it:
> >
> > .\" We must use consecutive page numbers when using PostScript to
> > .\" generate HTML images, and we must not reset the page number at the
> > .\" beginning (the 'ps4html' register is automatically added to the
> > .\" command line by the pre-HTML preprocessor).
> > .if !r ps4html \
> > .  if r P .pn 0\n[P]
> > .if !r cR \{\
> > .  ie n .nr cR 1
> > .  el   .nr cR 1
> > .\}
> 
> I must caution you that setting the `cR` register (it's short for
> "continuous rendering") when the formatter is not in "nroff mode", which
> is what the above code does, is going to result in bad typesetting for
> PostScript, PDF, DVI, and some more obscure output devices.  But it
> won't hurt terminal output, which already uses continuous rendering
> (because terminal devices are always in "nroff mode").  The `cR`
> register is documented in groff_man(7).  The `ps4html` register is...not
> documented.  :-|

Thank you for advising me against this

And by the looks of it, neither is mso. And this is important. Very
important.

> 
> > Quite honestly,  I don't understand much of the macros initials,
> 
> The requests themselves, `if`, `ie`, `el`, `pn`, and `nr` are documented
> in the groff(7) man page and groff's Texinfo manual.

thank you Branden. But before continuing with what and whatnot is
documented, it would be advisable to clarify what man page are we
exactly referring to here.

What I'm trying to say is that we need (not need, my mistake on
using t hat term, but rather ought to be, I think) in the proverbial
'same page' to avoid inferring the wrong conclusions, maybe? .
Earlier on this thread you referred me to further read/consult a section
aptly named "Files". But unfortunately, that section "Files" does not exist in
any shape or form on the man pages I had been following/reading.

As a result, this leads to even more confusion than what was intended, or
what was planned. 

Let me ask you something, if you wouldn't mind. What happened to the other folks
who wrote the man pages I've been reading? Did they retire or burnt
out. Nothing wrong with burnt out, I'm burnt out already and haven't
even put a fraction of that documentation in place. But I can see that you 
mentioned
some of these individuals in the man pages you referenced, but most
important of all, is that the references to what you're alluding are
not the same references by which I or any other user out there, are relying
solely upon. The contents of these man pages differ in
scope and details from one another .

Hear me out for a second here please. Most distributions out there,  most,
and I'm not going to say only a handful of them, but most of them, prepackage 
the
man pages written by the other folks and not the updated version as
you've been referring to here. 

It's praiseworthy that you and others are updating all of this
documentation, but I wouldn't like to suddenly drop the old documentation
like a hot potato just because lots of changes/fixes have taken
place.. Perhaps I should do so to keep up with the latest … 
But I would rather keep the old documentation. Omissions on the current
version do not document the same.

Of course. I'm assuming that most folks who follow groff development
to various degrees, are aware of all this updating that goes on behind
the scenes with its documentation and programs, but I can't warrant
the same conclusion that the majority of users or end-users would
follow suit as the rest. Doing so would be fallacious.

But I'll keep both 1.22 and 1.23 


> 
> > So I thought: perhaps an-old.tmac would give me some clues, so I went
> > there, and cR looked like a candidate,  a nd I just modified the
> > values from 0 to 1 and it worked :) But it turns out: it's a
> > register!!!
> >
> > Ignorance is bliss. I tell you. A register with different values that
> > caught my attention. That's funny :)
> 
> I think what happened is that by making this change, you masked a bug in
> /etc/groff/man.local.
> 
> It's okay to claim victory and move on if things are working to your
> satisfaction, but the change you made is a hack with undesirable side
> effects that you might care about later.  I would add a comment to
> yourself in the file documenting the change you made and why.  Six
> months from now, if you're trying to format a man page in PDF and it
> looks crazy, you'll have an easier time locating the source of the
> trouble.
> 

I believe it and it would be the correct course of action documenting
 as you said with a personal note what this was all about. A minor
 kludge that may/possibly affect formatting,
or doesn't seem to be affecting formatting while loading man macros. I
could be wrong here, but the pages I was testing them under, rendered
relatively acceptable.

But if .mso would have loaded man.local from the very beginning,
you'd be definitely correct in your assessment and the victory would
be all yours, but it doesn't load the man.local file. In retrospect
I can't give you the medal either.

The documentation for version 1.22.4 says the following

 mso filename
             Load a macro file using the search path.  Ignored because
             insecure.

And also

.mso file The same as .so except that file is searched in the tmac
                 directories


The former is as problematic or even more so, than a bad formatting. 

.mso is not documented on 1.23 

Perhaps I'm beginning to understand the rationale from Alpine in going
that route. 

So (no pun intended), is ignored default for both .mso and .so? 

Isn't that great 

I'm assuming it is, because that was the problem. 

But on the other hand, what an-old.tmac seems to be doing, is
forcing the loading of a  man.local regardless. (this is according to
the documentation that states mso is ignored).


> > Besides, Version 1.23 compiled fine and produced the page/s without
> > the blank page why would locales be a problem, I thought.
> >
> > But what this confirms in a way, to a certain extent, is that the
> > output from what the tty showed at first, correlates with this
> > behavior. I think.
> >
> > On the other spare system I have, all the files from the tmac dir are
> > the same as the ones on Alpine. And an-old.tmac there, odviously shows
> > the two values originally as CR 1 and CR 0 and it never produced an
> > extra blank page either, whereas with this system  under Alpine,  it
> > does. Except version 1.23 of course.
> 
> All of the above suggests to me that /etc/groff/man.local, or one of the
> macro files, got corrupted on that Alpine Linux system running groff
> 1.22.4.  I would still look for blank lines in macro files, and make
> sure there are none that are harmful.  (A blank line between lines `.ig`
> and `..` is harmless as discussed earlier.)
> 
> grep '^$' whatever.tmac
> 
> > Thank you Branden. I appreciate it.
> 
> You're welcome.  If you're happy, I'm happy--but I also fear you'll be
> unhappy again in the future if you don't locate the root cause of the
> problem.
> 

I believe your advice is in good faith and for a good reason, but the whole
.mso and .so is unsettling too. 

> Regards,
> Branden

take care Branden. 



-- 
        A novice programmer was once assigned to code a simple financial
package.
        The novice worked furiously for many days, but when his master
reviewed his program, he discovered that it contained a screen editor, a set
of generalized graphics routines, and artificial intelligence interface,
but not the slightest mention of anything financial.
        When the master asked about this, the novice became indignant.
"Don't be so impatient," he said, "I'll put the financial stuff in
eventually."
                -- Geoffrey James, "The Tao of Programming"