[bug #59962] Issues in Groff man pages

[G. Branden Robinson]

Update of bug #59962 (project groff):

                Severity:              3 - Normal => 2 - Minor              
                  Status:                    None => Need Info              
             Assigned to:                    None => gbranden               

    _______________________________________________________

Follow-up Comment #1:

[comment #0 original submission:]
Hi Helge,

Thanks for the report.

> Man page: groff.1.po
> Issue: Why B<and> but not B<7>?
> 
> "I<groff> has man pages in sections B<1>,B< 5>,B<and> 7B<.>"

This was fixed on 15 September 2020. 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=550ab5338e04e54539214997315f451c89ac25e6

> --
> Man page: groff.1.po
> Issue: English sentence broken (and sentence garbage: »in the same
section« and »with the lowset section«)
> 
> "When there are several I<man pages> with the same name in the same I<man>
"
> "section, the one with the lowest section is should as first."

As above.

> --
> Man page: soelim.1
> Issue: The following graphs cannot be processed by po4a. To ease
translation, please render this directly, avoiding pic.tmac. See bootup(7) for
an example
> 
> "The normal processing sequence of groff is this:"

Hmmm, it may be desirable to enhance your toolchain, or possibly to
special-case your project's handling of GNU soelim, since its usage of the pic
preprocessor in a man page document is, to the best of my knowledge, rare. 
(However, your project likely has access to better raw data on this issue than
I do.)

What I believe should excuse soelim(1) from complaint is that it only uses pic
if the formatter is in "troff mode"--this is the "t" conditional in troff.  In
soelim(1) we have in-page logic that boils down to this:


.if t
.PS
.\" pic diagram
.PE
.el
.\" ASCII art alternative


On further consideration, the quoted strings in the pic document are also
legitimate strings for localization, so again this may boil down to a
toolchain issue, because these should be easy to match.  (The fixed sizes of
the geometric objects surrounding the text could prove troublesome,
admittedly.  Possibly some sufficiently clever pic-writing could overcome this
by measuring the strings and sizing the objects to fit them.)

In my view, having a fallback/alternative for nroff devices is not only the
right thing to do for accessibility purposes, but it should be showing up as
localizable text.

Can you share any insight on these matters?

> --
> Man page: soelim.1
> Issue: missing whitespace
> 
> "B<-I>I<dir>"

This was fixed on 8 October 2020. 
https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7eca9c3c6d0efdbb29dcedad51d18d4c4993a22a

The issues already fixed are expected in the groff 1.23.0 release, and the
release candidate available at https://alpha.gnu.org/gnu/groff/ already
reflects them.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59962>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/