Re: [bug #59424] tmac/groff_mdoc.7.man: one table is wider than the line width (80)

[Bjarni Ingi Gislason]

On Fri, Nov 06, 2020 at 05:59:16PM -0500, G. Branden Robinson wrote:
> Update of bug #59424 (project groff):
> 
>                   Status:                    None => Confirmed              
>              Assigned to:                    None => gbranden               
> 
>     _______________________________________________________
> 
> Follow-up Comment #1:
> 
> [comment #0 original submission:]
> > Subject: tmac/groff_mdoc.7.man: one table is wider than the line width (80)
> > 
> >   "man -l tmac/groff_mdoc.7.man"
> 
> I can't reproduce this, but as a point of general advice I don't recommend
> running man directly on man pages in the groff source tree, because they
> haven't gone through sed substitution (and, in groff_man(7)'s case, digestion
> by m4).
> 

  In this exceptional case both versions are the same.

  I used the ".man" file to get the line number "correct",
as I assumed,
it could be (is) different from the file in the "build" directory.

> Preview development groff pages by doing a build first.  You can then examine
> their generated forms, whose file names end in ".1", ".5", and ".7".
> 
> Even then, previewing with man(1) must be done with caution, because groff--it
> should go without saying--provides much of the infrastructure that man(1) uses
> for page rendering.  I came to learn this lesson myself after I started making
> changes to the "an" macro package.
> 
> > (using "test-nroff -mandoc -rF=0 -P-i -dAD=l -rHY=0")
> 
> This information is only partially helpful; "test-nroff" is not something that
> is in public distribution or that anyone can be expected to have (as far as I
> know, you're the only person on the planet with such a script).  When
> reporting bugs, be sure you can reproduce the problem exclusively using tools
> in general distribution.
> 

  I will add the content of my ~/.manpath to the error file from "man",
which is:

DEFINE  troff   test-groff -mandoc -rF=0
DEFINE  nroff   test-nroff -mandoc -rF=0 -P-i -dAD=l -rHY=0
# test-nroff is in my git/groff repository and is similar to "nroff" there,
# except "test-groff" is used instead of "groff".

> Furthermore, the -rF=0 flag is spurious for this report.  I realize that this
> option may be standard procedure for you to work around other, less fastidious
> man pages, but when reporting a bug, a _minimal_ reproducing case is of
> greater value.
> 

  Yes, but for me, it is the minimal input (shortest input file).

> > and with environment
> > 
> > MANWIDTH=80
> > MAN_KEEP_STDERR=yes
> 
> Hmm, yes, I can't reproduce the problem even with -rLL=78n, the line length
> man-db man(1) uses by default, and it is even shorter.
> 

  I forgot to mention this in the environment:

MANOPT=-E latin1 --no-hyphenation --no-justification --warnings=w

> > shows on standard error:
> > 
> > warning: file '<standard input>', around line 4108:
> >   table wider than line width
> 
> The above reveals that the tbl(1) you're using is not from groff Git, because
> it lacks commit f75e156b621d3743368c58425f357e6cd52372a0.
> 

  There was a bug in my script causing "man" to use the installed system
files for the groff-related binaries (Debian package).

  After adding "~/git/groff/build" to the PATH, the same "filename" was
used in the warning.

"man" probably uses a different pipeline than "groff".

  "man -d ..." does not show the pipeline it constructs.

N.B.  The GNU standard recommends:

"   Error messages from other noninteractive programs should look like
this:

     PROGRAM:SOURCEFILE:LINENO: MESSAGE
"

  The standard does not say what the "PROGRAM" should contain,
but a sensible choice is

  1) the name of the binary that contains the MESSAGE,

  2) the name of the binary and the file,
that contains the MESSAGE.

So reporting, who, where,and what.

[...]

> Wait.  After writing all that, I realized the problem.
> 
> You're not rendering to -Tutf8, but -Tascii or -Tlatin1.  Those encodings lack
> an infinity sign and make the UCS column much wider, which in turn causes the
> >= and <= rows to overrun.
> 

  I will add the value of the used character set with "locale -k charmap"
in the error file from "man".

(which is: charmap="ISO-8859-1".)

  It is easier to remove lines, than to add ones.

> I stand by most of the above advice, regardless, and would add: always tell us
> which device you're rendering for.
> 
>     _______________________________________________________

  Thanks for your feedback.

N.B.  There is a typo (mistyping) in "lowecase pi".

-- 
Bjarni I. Gislason