bugGNU roff - Bugs: bug #66103, man pages should refer to...

 
 

bug #66103: man pages should refer to "ISO/IEC" standards

Submitter:  Helge Kreutzmann <kreutzm>
Submitted:  Sun 18 Aug 2024 05:53:10 PM UTC
   
 
Category:  General Severity:  2 - Minor
Item Group:  Documentation Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 24 Jun 2025 10:52:35 PM UTC, comment #13: 

Updating Summary to reflect the scope as eventually amended.

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Sep 2024 05:27:38 PM UTC, comment #12: 

At 2024-09-14T13:17:52-0400, Helge Kreutzmann wrote:

> regarding po4a macros - I'm also sometimes learning by Martin Quinson
> (maintainer of po4a) reply to my bug reports there.The best source I know of
> is Locale::Po4a::Man(1).


Ah, thanks--I had poked my nose all over perlpod and podlators stuff.

> Thanks for handling the ISO/IEC reference.
>
> As you reopend this, I notice the following when updating the markers in
> manpages-l10n:
>
> Wouldn't it be the following correction:
>
> B<-r\\ >I<cnumeric-expression> -> B<-r\\ c>I<numeric-expression>
> i.e. put the "c" into the bold part as well, as it is not part of the numeric
> expression? Or did I misunderstand your rationale?


No.  "c" is a parameter and so is "numeric-expression".

It has for decades been possible to do the following with *roff
formatters.


PDP-11 simulator V3.8-1
Disabling XQ
@boot
New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)rl2unix
mem = 177856
# Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 22:20:25 EDT 1988

login: dmr
$ echo '.tm n=\nn' | nroff -rn1+2+2+1
n=6


In the foregoing, "n" is a single-letter register name.  I could have
chosen "a", "z", or more exotic possibilities, some of which would have
required escaping in a shell command.

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Sep 2024 05:17:49 PM UTC, comment #11: 

Hello Branden,
regarding po4a macros - I'm also sometimes learning by Martin Quinson (maintainer of po4a) reply to my bug reports there.The best source I know of is Locale::Po4a::Man(1).

Thanks for handling the ISO/IEC reference.

As you reopend this, I notice the following when updating the markers in manpages-l10n:

Wouldn't it be the following correction:

B<-r\\ >I<cnumeric-expression> -> B<-r\\ c>I<numeric-expression>
i.e. put the "c" into the bold part as well, as it is not part of the numeric expression? Or did I misunderstand your rationale?

Greetings

        Helge

Helge Kreutzmann <kreutzm>
Sat 14 Sep 2024 05:03:44 PM UTC, comment #10: 

Hi Helge,

At 2024-09-14T12:35:35-0400, Helge Kreutzmann wrote:

> thanks for handling the report. I'll note down where you are not in
> agreement with the report, so it won't be reported again in the
> future.


Okay.  I won't get upset if they are.  I can cross-reference back
to this one if necessary.  :)

> Regarding the questions raised, here is my reply. It's a bit tough in
> this form, so please accept that citing is difficult.


Understood.

> 1. Man rules:
> If in doubt, I look at man-pages(7).


That's a good resource, and has gotten better over the years, but it's a
style guide specifically for the Linux man-pages project.  groff is
not the same project.  While I, like Ingo, believe there should be
considerable parity between projects' man page styling practices, I am
willing to go only so far as a prescriptivist.  I have my own conscience
to struggle with.  ;-)

groff's own style guide for man pages is in, you won't be surprised to
learn, groff_man_style(7).

> I'm not judging it, but given also this thread, I noticed e.g. the
> following changes:


> -Any reference to another man page should be written with the name in bold


This is a matter of preference and moreover of historical mutation, as I
explored at length in one of the URLs in comment #1.  Importantly, an
explicit design objective of the new `MR` macro is to give the user--the
person typing "man whatever"--a means of expressing that preference such
that a man(7) document will honor it.

groff_man(7):

Options
     The following groff options set registers (with -r) and strings
     (with -d) recognized and used by the man macro package.  To ensure
     rendering consistent with output device capabilities and reader
     preferences, man pages should never manipulate them.
...
     -dMF=man‐page‐topic‐font
              Select the font used for man page identifiers in .TH calls
              and topics named in .MR calls; the default is “I” (italic
              style of the default family).  Any valid argument to
              groff’s “.ft” request may be used.  If the MF string ends
              in “I”, the package assumes it to be an oblique typeface,
              and applies italic corrections before and after man page
              topics and identifiers.


mdoc(7) from
[https://git.savannah.gnu.org/cgit/groff.git/tree/macros/tmac.doc?h=1.02
day one (or 1990 at the latest)] supported an extensive mechanism for
user customization of the styling of most formatting macros.  I don't
know to what extent Ingo's mandoc(1) supports that, but groff has done
so for 34+ years.

> -The list below shows conventional or suggested sections.
> Again, no judgement, just an observation.


Acknowledged.

> 2. No E<.MR ..> does not mean error. It is a way for po4a to express to insert
> the new MR macro.


Ahh, interesting!  E<> is new to me; I'm familiar with B<> and I<> and I
think there's a C<> or maybe an L<>?  I've looked in vain for a
canonical reference to all such po4a tags.  Can you point me to one?

> 3. List styles/colons: I've seen (also in other context) different
> conventions, but I'm not a native speaker, so I simply wanted to point
> this (potential) issue out. (And see comment #7)


Native speech might not help.  One groff developer from the U.K.
starts such colon-introduced lists like this:-

...like a discombobulated obelus ÷.  I seldom see that orthography
anywhere, but when I do, it seems to be a Commonwealth practice.

I lump it in with fortnights, ha'pennies and unleavened "biscuits".  ;-)

> 4. Regarding ISO/IEC: I know the difference, I'm editor of several
> ISO/IEC standards and I double checked each proposal. This was not
> done blindly.  (And yes, this is ISO 9001, I'm aware).


Ah, excellent!

> If you want to check yourself: Insert the standard number in question
> in www.iso.org. If it comes from ISO/IEC JTC1 (the group responsible
> for joint standards), then it is written out. (This is what I did for
> every report on this matter).


Thank you for the link, the advice, and for researching the background.
I'll reopen the ticket to reflect the need to address this issue.

> I was basically correcting it as "IEC" is often left out, even though
> it is a joint standard.


Yes.  I've seen it omitted so often that I am left with little intuition
as to whether any given ISO standard commonly cited by Unix developers
is a joint one with IEC or not.

> 5.Regarding cross reference - I acknowledge your decision, I'm
> personally fond of have more then less cross references or bold
> typeface for self reference. I think it helps for consistency and do
> not feel it "nosy". But again, this is just my personal impression.
> (In agreement with Comment 4)


Acknowledged.

> 6. Regarding the decision to have different terms in the synopsis and
> later on in the man page - ok, I'm just worried it might confuse
> readers. But again, I did not do any study on this.


It's a relatively recent initiative of mine in my development as a
technical writer.  I might come to repent of it.  But right now, I think
it better than the alternative, for the reasons I proffered.

Regards,
Branden

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Sep 2024 04:36:24 PM UTC, comment #9: 

The blank comments in this ticket's history are discussed in Savannah support ticket #111122.

G. Branden Robinson <gbranden>
Group administrator
Sat 14 Sep 2024 04:35:31 PM UTC, comment #8: 

Hello Branden,
thanks for handling the report. I'll note down where you are not in agreement with the report, so it won't be reported again in the future.

Regarding the questions raised, here is my reply. It's a bit tough in this form, so please accept that citing is difficult.

1. Man rules:
If in doubt, I look at man-pages(7). I'm not judging it, but given also this thread, I noticed e.g. the following changes:
-Any reference to another man page should be written with the name in bold
-The list below shows conventional or suggested sections.
Again, no judgement, just an observation.

2. No E<.MR ..> does not mean error. It is a way for po4a to express to insert the new MR macro.

3. List styles/colons: I've seen (also in other context) different conventions, but I'm not a native speaker, so I simply wanted to point this (potential) issue out. (And see comment #7)

4. Regarding ISO/IEC: I know the difference, I'm editor of several ISO/IEC standards and I double checked each proposal. This was not done blindly. (And yes, this is ISO 9001, I'm aware).
If you want to check yourself:
Insert the standard number in question in www.iso.org. If it comes from ISO/IEC JTC1 (the group responsible for joint standards), then it is written out. (This is what I did for every report on this matter).
I was basically correcting it as "IEC" is often left out, even though it is a joint standard.

5.Regarding cross reference - I acknowledge your decision, I'm personally fond of have more then less cross references or bold typeface for self reference. I think it helps for consistency and do not feel it "nosy". But again, this is just my personal impression. (In agreement with Comment 4)

6. Regarding the decision to have different terms in the synopsis and later on in the man page - ok, I'm just worried it might confuse readers. But again, I did not do any study on this.

And thank you very much for the long explanations.

Greetings

        Helge

Helge Kreutzmann <kreutzm>
Thu 12 Sep 2024 09:59:14 PM UTC, comment #7: 

comment #1:

> Use of a colon is poor grammar when the ensuing list fails to
> exhibit sentence-ending punctuation,


Avoiding such constructions is a valid style choice, but it's hard to justify calling it poor grammar when respected style guides like the Chicago Manual of Style endorse the practice.

The CMOS is behind a paywall, so I can't link to its online version, but section 6.141 of the just-released 18th edition says, "A vertical list is best introduced by a grammatically complete sentence, followed by a colon."  This advice goes back to at least the 13th edition (section 5.78, though it's more limited in scope there), predating your nemesis Russell Harper's hand on the CMOS tiller.

While the 6.141 text doesn't directly address post-list terminal punctuation, multiple examples in the section show none after the list--which is reasonable, since, absent a continuation of the introducing sentence, how would one even place terminal punctuation in a way that wouldn't look ridiculous?

Dave <barx>
Group Member
Thu 12 Sep 2024 03:50:17 PM UTC, comment #6: 


commit d3632851e229795890d3cad64a52881e72a56698
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Wed Sep 11 08:19:55 2024 -0500

    groff(1), soelim(1): Hyperlink more xrefs.

    * src/preproc/soelim/soelim.1.man (Description):
    * src/roff/groff/groff.1.man (groff-specific options, Usage)
      (Getting started): Hyperlink man page cross references on first
      occurrences.

    Fixes <https://savannah.gnu.org/bugs/?66103>.  Thanks to Helge
    Kreutzmann and the manpage-l10n project for the report.

    ANNOUNCE: Acknowlede Helge.


G. Branden Robinson <gbranden>
Group administrator
Thu 12 Sep 2024 05:18:24 AM UTC, comment #5: 


G. Branden Robinson <gbranden>
Group administrator
Wed 11 Sep 2024 03:09:38 PM UTC, comment #4: 


>> Man page: soelim.1
>> Issue 1:  I<\\%soelim> → B<\\%soelim>
>> Issue 2:  I<\\%troff> → .MR \\%troff 1
>>
>> "I<\\%soelim> is I<not> required for I<\\%troff> to source files."


> As this is the very next sentence, another cross reference here would be
> superfluous.
>
> Automated style checking is a valuable thing to have, but technical
> writing, if it is be of sufficient quality to engage a human reader
> productively, is not a robotic practice.  I counsel against a lazy
> prescription that every single mention of a word that might be a man
> page cross reference should be marked up as such.


While i agree with gbranden@ that technical writing must not be robotic,
we do have the prescription in OpenBSD manual pages that every single
mention of a word that would be a manual page cross reference if it
were the only mention of that word in that page should be marked up as such,
even if it appears repeatedly in the same paragraph or sentence.

With traditional mdoc(7) formatting conventions (still used by mandoc(1)
and *BSD in general) a manual page reference is set as name(section)
all in the default Roman font, which is not noisy at all.  There is
value in unambiguously marking up words as being intended as a reference
to a specific documented command, function, or concept, and not only
being a normal English word.

This is not intended to restart an old controversy - i highly respect
gbranden@, but we are known to disagree on this particular point.

I mention this for the benefit of the manpage-10n crowd.  The lesson is
that while there is consensus about most aspects of manual page formatting,
a few details do exist where different projects prefer different
conventions, both with respect to technical writing style guidelines
and with respect to markup - and sometimes both aspects even interact
with each other, meaning that decisions on one side influence what
makes most sense on the other side.

Unfortunately, such slight differences in conventions make cross-project
markup and style checking harder, but it's still a good thing that you
try.  Thank you for attempting such work inside manpage-10n.

Ingo Schwarze <schwarze>
Group Member
Wed 11 Sep 2024 08:40:41 AM UTC, comment #3: 

Looks like Savane got angry with me.

Here's what I tried to reply with via email:


Subject: Re: [bug #66103] manpage-10n project: issues in man pages

[self-follow-up]

I had a wordo here.

At 2024-09-11T04:33:41-0400, G. Branden Robinson wrote:
> Yes.  These are all deliberate.  The idea is to have the synopsis
> synopsize, and to keep it in parallel with the command's usage message,
> which does describe each option in detail.

...does _NOT_ describe each option in detail.

Some commands do employ long usage messages, for those I would recommend
a similar practice as groff(1): give people self-documenting argument
names in the synopsis, since some users require only an aide-mémoire,
and terser ones when presenting the semantics of an option.

>   {savane: user = 108747; tracker = bugs; item = 66103}

Regards,
Branden


G. Branden Robinson <gbranden>
Group administrator
Wed 11 Sep 2024 08:38:00 AM UTC, comment #2: 


G. Branden Robinson <gbranden>
Group administrator
Wed 11 Sep 2024 08:33:38 AM UTC, comment #1: 

At 2024-08-18T13:53:13-0400, Helge Kreutzmann wrote:

> Please note: I know you are not following traditional man rules any
> more,


I dispute that.  I think groff's man pages are as faithful to the format
and conventions established in the Seventh Edition Unix Programmer's
Manual as any other well-curated corpus of man pages.

I am happy to discuss particulars with you.

> so maybe some of the following issues are changes done on purpose,
> Those where I do not see updates I will mark appropriately, so that
> they are not reported in the future again.


Understood.

> Man page: groff.1
> Issue:    I<roff> → B<roff>(7)


Deliberate.  As far as the font style is concerned, I have explored this
matter at length.

https://lists.gnu.org/archive/html/groff/2023-08/msg00005.html

> "groff - front end to the GNU I<roff> document formatting system"
>
> "I<groff> is the primary front end to the GNU I<roff> document
> formatting " "system."


If the report is that "roff" and "groff" should be set in bold instead
of italics, or in roman, I do not agree and that is not convention
except in man pages authored with a poor grasp of tradition (or
deliberate deviation).

groff_man_style(7):
              Use italics for file and path names, for environment
              variables, for C data types, for enumeration or
              preprocessor constants in C, for variant (user‐
              replaceable) portions of syntax synopses, for the first
              occurrence (only) of a technical concept being introduced,
              for names of journals and of literary works longer than an
              article, and anywhere a parameter requiring replacement by
              the user is encountered.  An exception involves variant
              text in a context already typeset in italics, such as file
              or path names with replaceable components; in such cases,
              follow the convention of mathematical typography: set the
              file or path name in italics as usual but use roman for
              the variant part (see .IR and .RI below), and italics
              again in running roman text when referring to the variant
              material.

> Man page: groff.1
> Issue:    The variable strings here are different than in the description
> below, e.g. ctext, fallback-encoding, i.e.
>  cs or ctest?
>  fallback-encoding or enc?
>  font-family or fam?
>  font-directory or dir?
>  inclusion-directory or dir?
>  input-encoding or enc?
>  spooler-argument or arg?
>  macro-package or name?
>  macro-directory or dir?
>  page-number or num?
>  page-list or list?
>  postprocessor-argument or arg?
>  output-device or dev?
>  warning-category or name?


Yes.  These are all deliberate.  The idea is to have the synopsis
synopsize, and to keep it in parallel with the command's usage message,
which does describe each option in detail.

You should perceive parity between

Synopsis
       groff [-abcCeEgGijklNpRsStUVXzZ] [-d ctext] [-d string=text]
             [-D fallback‐encoding] [-f font‐family] [-F font‐directory]
             [-I inclusion‐directory] [-K input‐encoding] [-L spooler‐
             argument] [-m macro‐package] [-M macro‐directory] [-n page‐
             number] [-o page‐list] [-P postprocessor‐argument]
             [-r cnumeric‐expression] [-r register=numeric‐expression]
             [-T output‐device] [-w warning‐category] [-W warning‐
             category] [file ...]

       groff -h
       groff --help

       groff -v [option ...] [file ...]
       groff --version [option ...] [file ...]

and

$ groff --help
usage: groff [-abcCeEgGijklNpRsStUVXzZ] [-d ctext] [-d string=text] [-D fallback-encoding] [-f font-family] [-F font-directory] [-I inclusion-directory] [-K input-encoding] [-L spooler-argument] [-m macro-package] [-M macro-directory] [-n page-number] [-o page-list] [-P postprocessor-argument] [-r cnumeric-expression] [-r register=numeric-expression] [-T output-device] [-w warning-category] [-W warning-category] [file ...]
usage: groff {-v | --version}
usage: groff {-h | --help}

...for example.

groff (GNU roff) is a typesetting system that reads plain text input
files that include formatting commands to produce output in
PostScript, PDF, HTML, or DVI formats or for display to a terminal.
See the groff(1) manual page.

By contrast, when we present command-line options in the "Options"
section of a man page, there is no pressing need to have such lengthy,
descriptive parameter names, because these names are explicated in the
immediate context.  This convention should be familiar from mathematical
writing.

     -D enc   Use enc as preconv(1)’s fallback input encoding; implies
              -k.
...
     -I dir   Works as troff’s option (see below), but also implies -g
              and -s.  groff passes -I options and their arguments to
              soelim(1), troff(1), and output drivers; with the option
              letter changed to -M, the same arguments are passed to
              grn(1).
...
     -K enc   Set input encoding used by preconv(1) to enc; implies -k.
...
     -L arg   Pass arg to the print spooler.  If multiple args are
              required, pass each with a separate -L option.  groff does
              not prefix an option dash to arg before passing it to the
              spooler.
...
     -P arg   Pass arg to the postprocessor.  If multiple args are
              required, pass each with a separate -P option.  groff does
              not prefix an option dash to arg before passing it to the
              postprocessor.
...
     -T dev   Prepare output for device dev.  groff passes the -T option
              and its argument to troff, then (unless the -Z option is
              used) runs an output driver to convert troff’s output to a
              form appropriate for dev; see subsection “Output devices”
              below.

As you can see, it also makes for tidier typesetting.

I use long parameter names again where this page (unique in the groff
corpus) explicitly demurs from explaining them.

   Transparent options
     The following options are passed as‐is to the formatter program
     troff(1) and described in more detail in its man page.
...
     -d ctext
     -d string=text
              Define string.
...
     -r cnumeric‐expression
     -r register=numeric‐expression
              Define register.

> "The combination constitutes a document in one of a family of languages we "
> "also call I<roff>; see E<.MR roff 7> for background."


If "E" means "error", then it looks like your tools may want to adapt to
a new feature of groff 1.23's man(7) macros.

groff_man(7):
     .MR topic [manual‐section [trailing‐text]]
            (since groff 1.23) Set a man page cross reference as
            “topic(manual‐section)”.  If manual‐section is absent, the
            package omits the surrounding parentheses.  If trailing‐text
            (typically punctuation) is specified, it follows the closing
            parenthesis without intervening space.  Hyphenation is
            disabled while the cross reference is set.  topic is set in
            the font specified by the MF string.  If manual‐section is
            present, the cross reference hyperlinks to a URI of the form
            “man:topic(manual‐section)”.
...
     James Clark implemented the foregoing features in early versions of
     groff.  Later, groff 1.20 (2009) originated .SY/.YS, .TQ, .MT/.ME,
     and .UR/.UE.  Plan 9 from User Space’s troff introduced .MR in
     2020.

> Man page: groff.1
> Issue:    I<\\%grn> → MR  \\%grn 1 \\%grn 1
>
> "It is passed to E<.MR \\%soelim 1> and the output driver, and I<\\%grn> is "
> "passed an B<-M> option with I<dir> as its argument."


Fixed in groff Git since September 2023.

groff(1):
     -I dir   Works as troff’s option (see below), but also implies -g
              and -s.  groff passes -I options and their arguments to
              soelim(1), troff(1), and output drivers; with the option
              letter changed to -M, the same arguments are passed to
              grn(1).

> Man page: groff.1
> Issue 1:  I<\\%pic> → .MR \\%pic 1
> Issue 2:  I<\\%troff> → .MR \\%troff 1
>
> "Operate in unsafe mode: pass the B<-U> option to I<\\%pic> and I<\\%troff>."


Thanks for the report.

> Man page: groff.1
> Issue:    cnumeric-expression → numeric-expression
>
> "B<-r\\ >I<cnumeric-expression>"


This is not a typo, but an explication of the syntax, which admits no
separating space.  groff(1) defers explanation of this option, like `-d`
to troff(1).

groff(1):
   Transparent options
     The following options are passed as‐is to the formatter program
     troff(1) and described in more detail in its man page.

troff(1):
     -r cnumeric‐expression
     -r register=numeric‐expression
              Define roff register c or register as numeric‐expression.
              c must be a one‐character identifier; register can be of
              arbitrary length.  Such assignments happen before any
              macro file is loaded, including the startup file.  Due to
              getopt_long(3) limitations, c cannot be, and register
              cannot contain, an equals sign, even though that is a
              valid character in a roff identifier.

> Man page: groff.1
> Issue 1:  I<roff> → .MR roff 7
> Issue 2:  I<troff> → .MR \\%troff 1


I do not slavishly mark every occurrence of a potential man page cross
reference as such.  This can get noisy and repetitious.

Observe the specification of the `MR` macro.

groff_man(7):
     .MR topic [manual‐section [trailing‐text]]
            (since groff 1.23) Set a man page cross reference as
            “topic(manual‐section)”.  If manual‐section is absent, the
            package omits the surrounding parentheses.  If trailing‐text
            (typically punctuation) is specified, it follows the closing
            parenthesis without intervening space.  Hyphenation is
            disabled while the cross reference is set.  topic is set in
            the font specified by the MF string.  If manual‐section is
            present, the cross reference hyperlinks to a URI of the form
            “man:topic(manual‐section)”.

I do think that a cross reference should be written out in full
(which, in groff 1.23, will also hyperlink them on supporting devices)
on a first occurrence in a page.

> --
> Man page: groff.1
> Issue:    I<sed> → .MR sed 1
>
> "We used a I<sed> command only to eliminate the 65 blank lines that would "
> "otherwise flood the terminal screen."
> --


Thanks for the report.

> Man page: groff.1
> Issue 1:  I<nroff> → .MR nroff 1
> Issue 2:  I<troff> → .Mr troff 1
>
> "These have one- or two-letter names arising from intense practices of naming
> "
> "economy in early Unix culture, a laconic approach that led to many of the "
> "packages being identified in general usage with the I<nroff> and I<troff> "
> "option letter used to invoke them, sometimes to punning effect, as with "
> "\\[lq]man\\[rq] (short for \\[lq]manual\\[rq]), and even with the option "
> "dash, as in the case of the I<s> package, much better known as I<ms> or even
> "
> "I<-ms>."
>
> "It provides the features of the AT&T I<troff> and I<nroff> programs as well
> "
> "as many extensions."
> --


As above, this is an avoidance of slavish repetition.

> Man page: groff.1
> Issue:    Use colon at end of line?
> "An output device may be any of the following."
>
> "Once a E<.MR man 1> librarian program has located a man page, it may execute
> "
> "a I<groff> command much like the following."


Negative.  Use of a colon is poor grammar when the ensuing list fails to
exhibit sentence-ending punctuation, as is often the case in man pages
composed by inexpert (or indifferent) technical writers.

I editorialized about this problem four years ago.

commit 3afcaf0ed409093626c3a9fe346bd33afec60f29
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Sep 6 04:54:06 2020 +1000

    doc/groff.texi, groff_diff(7): Tweak example.

    It's like bathing a cat to get programmers to punctuate inset examples
    that are grammatically part of a sentence, as if they were part of a
    sentence.  People love to just trail off with "the following:", blitz
    the user with 1-100 lines of block-quoted literal, and then pretend they
    ended a sentence.  (This is suggestive of the console jockey ethos; once
    one has thrown code at you, they're done with you.)

    Mathematical literature is more careful.

    However, the man macros make doing the right thing difficult; in nroff
    mode there just aren't many font styles to go around, and while one
    could ".if t" around that problem, a miniature BSD daemon materializes
    on my shoulder and pokes me with a pitchfork if I even consider it.  And
    doing so doesn't help the likely majority of people who only read man
    pages in a terminal window.

    In the end the best solution is to just recast.  Our man pages are
    already overrun with lazy "sentences" ending in "the following:" and
    similar constructions anyway, so it's no burden to scrub out one more.

    tl;dr: A colon does not relieve you of your duty to finish a sentence.

> --
> Man page: groff.1
> Issue:    ISO 646 1991:IRV  → ISO/IEC 646:1991  (what des IRV stand for?)


IRV stands for "International Reference Version".

https://agimcami.wordpress.com/wp-content/uploads/2019/07/ascii-characters-set-aivosto-com.pdf

> "for terminals using the ISO 646 1991:IRV character set and encoding, also "
> "known as US-ASCII."
> --
> Man page: groff.1
> Issue:    ISO → ISO/IEC
> "for terminals using the ISO Latin-1 (ISO 8859-1)  character set and
> encoding."
>
> "for terminals using the ISO 10646 (\\[lq]Unicode\\[rq]) character set in "
> "UTF-8 encoding."
>
> "Conversely, the output device B<cp1047> is not available on systems based on
> "
> "the ISO\\ 646 or ISO\\ 8859 character encoding standards."
> --


As I understand it, ISO and IEC are not merged organizations.  It is
appropriate to denote a standard document as "ISO/IEC" when it is
actually issued under the joint aegis of the two bodies.

When making such a rewrite recommendation, you should cite an
authoritative reference indicating that the IEC has cosponsored the
document in question.

A blind sed(1) rewrite of "ISO" will not do.  One would not say "ISO/IEC
9000 quality management".

> Man page: groff.1
> Issue:    I<\\%gxditview> → .MR \\%gxditview 1
>
> "for previewing with I<\\%gxditview> using 75 dpi resolution and a 10-point "
> "base type size."
>
> "for previewing with I<\\%gxditview> using 75 dpi resolution and a 12-point "
> "base type size."
>
> "for previewing with I<\\%gxditview> using 100 dpi resolution and a 10-point
> "
> "base type size."
>
> "for previewing with I<\\%gxditview> using 100 dpi resolution and a 12-point
> "
> "base type size."
>
> "The B<-X> option overrides this selection, causing I<\\%gxditview> to serve
> "
> "as the output driver."


Aleady cross referenced earlier in the page.

     -X       Use gxditview(1) instead of the usual postprocessor to
              (pre)view a document on an X11 display.  Combining this
              option with “-T ps” uses the font metrics of the
              PostScript device, whereas the “-T X75”, “-T X75-12” “-T
              X100”, and “-T X100-12” options use the metrics of X11
              fonts.

> --
> Man page: groff.1
> Issue:    I<\\%afmtodit> → .MR \\%afmtodit 1
>
> "translates a PostScript Type\\ 1 font in PFB (Printer Font Binary)  format "
> "to PFA (Printer Font ASCII), which can then be interpreted by
> I<\\%afmtodit>."


Already cross referenced in the immediately preceding paragraph.

     afmtodit(1)
            creates font description files for PostScript Type 1 fonts.

> --
> Man page: groff.1
> Issue 1:  I<troff> → .MR troff 1
> Issue 2:  I<nroff> → .MR nroff 1
> Issue 3:  I<\\%soelim> → .MR soelim 1
> Issue 4:  I<\\%indxbib> → .MR indxbib 1
> Issue 5:  I<\\%lookbib> → .MR lookbib 1
>
> "Besides I<troff>, the prefix applies to the formatter I<nroff>; the "
> "preprocessors I<eqn>, I<grn>, I<pic>, I<\\%refer>, I<tbl>, and I<\\%soelim>;
> "
> "and the utilities I<\\%indxbib> and I<\\%lookbib>."


Similarly, the paragraph tags in subsection "Utilities" already cross
reference the latter three of these, and the former two earlier still.

> --
> Man page: groff.1
> Issue:    I<preconv>(1) → .MR preconv 1
>
> "The value of this variable is passed to the I<preconv>(1)  preprocessor's
> B<-"
> "e> option to select the character encoding of input files."
>
> "If set but empty, I<groff> calls I<preconv> without an B<-e> option."
> --


Cross-referenced earlier.

     -k       Run preconv(1) preprocessor.  Refer to its man page for
              its behavior if neither of groff’s -K or -D options is
              also specified.

> Man page: soelim.1
> Issue:    I<\\%soelim> → B<soelim>


Conventions are split here.  mandoc(1), and Thomas Dickey's man pages,
tend to boldface a page's own topic name(s) at every occurrence.  I
think this is too busy.

groff_man_style(7):
     Be frugal with italics for emphasis, and particularly with bold.
     Article titles and brief runs of literal text, such as references
     to individual characters or short strings, including section and
     subsection headings of man pages, are suitable objects for
     quotation; see the \(lq, \(rq, \(oq, and \(cq escape sequences in
     subsection “Portability” below.

I am not alone; also see
<https://uit.stanford.edu/accessibility/concepts/typography>.

> --
> Man page: soelim.1
> Issue:    I<roff> → .MR roff 7
>
> "I<soelim> was designed to handle situations where the target of a I<roff> "
> "source request requires a preprocessor such as E<.MR \\%eqn 1 ,> E<.MR \\"
> "%pic 1 ,> E<.MR \\%refer 1 ,> or E<.MR \\%tbl 1 .>"


Already cross referenced in the first sentence of the document.

Description
     GNU soelim is a preprocessor for the groff(7) document formatting
     system.  soelim works as a filter to eliminate source requests in
     roff(7) input; that is, it replaces lines of the form “.so
     included‐file” within each text input‐file with the contents of
     included‐file, recursively.

> Man page: soelim.1
> Issue:    I<\\%troff> → .MR troff 1
>
> "That is, files sourced with \\[lq]B<so>\\[rq] are normally read I<only> by "
> "the formatter, I<\\%troff>."


Thanks for the report.

> Man page: soelim.1
> Issue 1:  I<\\%soelim> → B<\\%soelim>
> Issue 2:  I<\\%troff> → .MR \\%troff 1
>
> "I<\\%soelim> is I<not> required for I<\\%troff> to source files."


As this is the very next sentence, another cross reference here would be
superfluous.

Automated style checking is a valuable thing to have, but technical
writing, if it is be of sufficient quality to engage a human reader
productively, is not a robotic practice.  I counsel against a lazy
prescription that every single mention of a word that might be a man
page cross reference should be marked up as such.

G. Branden Robinson <gbranden>
Group administrator
Sun 18 Aug 2024 05:53:10 PM UTC, original submission:  

Dear groff maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including groff) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

Please note: I know you are not following traditional man rules any
more, so maybe some of the following issues are changes done on purpose,
Those where I do not see updates I will mark appropriately, so that
they are not reported in the future again.

Man page: groff.1
Issue:    I<roff> → B<roff>(7)

"groff - front end to the GNU I<roff> document formatting system"

"I<groff> is the primary front end to the GNU I<roff> document formatting "
"system."
--
Man page: groff.1
Issue:    The variable strings here are different than in the description below, e.g. ctext, fallback-encoding, i.e.
 cs or ctest?
 fallback-encoding or enc?
 font-family or fam?
 font-directory or dir?
 inclusion-directory or dir?
 input-encoding or enc?
 spooler-argument or arg?
 macro-package or name?
 macro-directory or dir?
 page-number or num?
 page-list or list?
 postprocessor-argument or arg?
 output-device or dev?
 warning-category or name?

"[B<-abcCeEgGijklNpRsStUVXzZ>] [B<-d\\ >I<ctext>] [B<-d\\ "
">I<string>B<=>I<text>] [B<-D\\ >I<fallback-encoding>] [B<-f\\ >I<font-"
"family>] [B<-F\\ >I<font-directory>] [B<-I\\ >I<inclusion-directory>] [B<-"
"K\\ >I<input-encoding>] [B<-L\\ >I<spooler-argument>] [B<-m\\ >I<macro-"
"package>] [B<-M\\ >I<macro-directory>] [B<-n\\ >I<page-number>] [B<-o\\ "
">I<page-list>] [B<-P\\ >I<postprocessor-argument>] [B<-r\\ >I<cnumeric-"
"expression>] [B<-r\\ >I<register>B<=>I<numeric-expression>] [B<-T\\ "
">I<output-device>] [B<-w\\ >I<warning-category>] [B<-W\\ >I<warning-"
"category>] [I<file\\ >.\\|.\\|.]"
--
Man page: groff.1
Issue:    I<roff> → .MR roff 7

"GNU I<roff> is a typesetting system that reads plain text input files that "
"include formatting commands to produce output in PostScript, PDF, HTML, DVI, "
"or other formats, or for display to a terminal."

"The front end programs available in the GNU I<roff> system make it easier to "
"use than traditional I<roff>s that required the construction of pipelines or "
"use of temporary files to carry a source document from maintainable form to "
"device-ready output."

"The discussion below summarizes the constituent parts of the GNU I<roff> "
"system."

"(I<roff> systems were developed in the days of paper-based terminals with 66 "
"lines to a page.)"

"Input to a I<roff> system is in plain text interleaved with control lines "
"and escape sequences."

"The combination constitutes a document in one of a family of languages we "
"also call I<roff>; see E<.MR roff 7> for background."

"An overview of GNU I<roff> language syntax and features, including lists of "
"all supported escape sequences, requests, and predefined registers, can be "
"found in E<.MR groff 7 .>"

"A preprocessor interprets a domain-specific language that produces I<roff> "
"language output."

"Frequently, such input is confined to sections or regions of a I<roff> input "
"file (bracketed with macro calls specific to each preprocessor), which it "
"replaces."

"Preprocessors therefore often interpret a subset of I<roff> syntax along "
"with their own language."

"Macro files are I<roff> input files designed to produce no output themselves "
"but instead ease the preparation of other I<roff> documents."

"Macro packages can be loaded prior to any I<roff> input documents with the "
"B<-m>\\ option."

"(invariably called \\[lq]mom\\[rq])  is a modern package written by Peter "
"Schaffter specifically for GNU I<roff>."

"I<\\%andoc> is a wrapper package specific to GNU I<roff> that recognizes "
"whether a document uses I<man> or I<mdoc> format and loads the corresponding "
"macro package."

"Many macro files augment the function of the full-service packages, or of "
"I<roff> documents that do not employ such a package\\[em]the latter are "
"sometimes characterized as \\[lq]raw\\[rq]."

"The formatter, the program that interprets I<roff> language input, is E<.MR "
"\\%troff 1 .>"

"The postprocessors provided by GNU I<roff> are I<output drivers>, which "
"prepare a document for viewing or printing."

"GNU I<roff> includes a suite of utilities."

"marks differences between a pair of I<roff> input files."

"A trio of tools transform material constructed using I<roff> preprocessor "
"languages into graphical image files."

"If it is not set, the installation directory of the GNU I<roff> executables, "
"I</usr/\\:\\%bin>, is searched before I<PATH>."

"I<roff> systems are best known for formatting man pages."

"To process a I<roff> input file using the preprocessors I<\\%tbl> and I<\\"
"%pic> and the I<me> macro package in the way to which AT&T I<troff> users "
"were accustomed, one would type (or script)  a pipeline."

"Most macro files supplied with GNU I<roff> are stored in I</usr/\\:\\%share/"
"\\:\\%groff/\\:\\%1.23.0/\\:\\%tmac> for the installation corresponding to "
"this document."

"For a catalog of macro files GNU I<roff> provides, see E<.MR groff_tmac 5 .>"

"Device and font description files supplied with GNU I<roff> are stored in I</"
"usr/\\:\\%share/\\:\\%groff/\\:\\%1.23.0/\\:\\%font> for the installation "
"corresponding to this document."
--
Man page: groff.1
Issue:    I<groff> → B<groff>

"If no I<file> operands are specified, or if I<file> is \\[lq]B<->\\[rq], "
"I<groff> reads the standard input stream."

"A reimplementation and extension of the typesetter from AT&T Unix, I<groff> "
"is present on most POSIX systems owing to its long association with Unix "
"manuals (including man pages)."

"I<groff> is capable of producing typographically sophisticated documents "
"while consuming minimal system resources."

"The I<groff> command orchestrates the execution of preprocessors, the "
"transformation of input documents into a device-independent page description "
"language, and the production of output from that language."

"Because I<groff> is intended to subsume most users' direct invocations of "
"the E<.MR \\%troff 1> formatter, the two programs share a set of options."

"Refer to its man page for its behavior if neither of I<groff>'s B<-K> or B<-"
"D> options is also specified."

"I<groff> does not prefix an option dash to I<arg> before passing it to the "
"spooler program."

"Write version information for I<groff> and all programs run by it to the "
"standard output stream; that is, the given command line is processed in the "
"usual way, passing B<-v> to the formatter and any pre- or postprocessors "
"invoked."

"Output the pipeline that I<groff> would run to the standard output stream, "
"but do not execute it."

"Those with a programmer's bent may be pleased to know that they can use "
"I<groff> in a read-evaluate-print loop (REPL)."

"I<groff> uses the command-line option B<-P> to pass options to output "
"devices; for example, use the following for PostScript output on A4 paper in "
"landscape orientation."

"Use the E<.MR grog 1> program to infer an appropriate I<groff> command line "
"to format a document."

"infers the I<groff> command a document requires."

"Using I<groff>, this pipe can be shortened to an equivalent command."
--
Man page: groff.1
Issue 1:  I<groff> → B<groff>
Issue 2:  I<\\%troff> → .MR troff 1

"However, I<groff> has some options that I<\\%troff> does not share, and "
"others which I<groff> interprets differently."

"The following options either do not exist in GNU I<troff> or are interpreted "
"differently by I<groff>."

"I<groff> then calls an output driver to convert I<\\%troff>'s output to a "
"form appropriate for I<dev>; see subsection \\[lq]Output devices\\[rq] below."
--
Man page: groff.1
Issue:    I<\\%troff> → .MR troff 1

"At the same time, not all valid I<\\%troff> options can be given to I<groff>."

"Works as I<\\%troff>'s option (see below), but is also passed to E<.MR \\"
"%eqn 1 ,> E<.MR grap 1 ,> and E<.MR \\%grn 1 .>"

"Direct I<\\%troff> to format the input for the output device I<dev>."

"I<\\%troff> output will appear on the standard output stream (unless "
"suppressed with B<-z>); see E<.MR groff_out 5> for a description of this "
"format."

"Enable AT&T I<troff> compatibility mode; implies B<-c>."

"Inhibit I<\\%troff> error messages; implies B<-Ww>."

"Suppress formatted device-independent output of I<\\%troff>."

"The I<papersize> macro package, automatically loaded by I<\\%troff>, "
"provides an interface for configuring page dimensions by convenient names, "
"like \\[lq]letter\\[rq] or \\[lq]A4\\[rq]; see E<.MR groff_tmac 5 .>"

"Tokens are generally preserved in preprocessor output and interpreted as "
"macro calls subsequently by I<\\%troff>."

"GNU I<troff> generates output in a device-independent, but not device-"
"agnostic, page description language detailed in E<.MR groff_out 5 .>"

"I<\\%troff> output is formatted for a particular I<output device>, typically "
"specified by the B<-T> option to the formatter or a front end."

"Any program that interprets the output of GNU I<troff> is a postprocessor."

"adds information to AT&T I<troff> font description files to enable their use "
"with GNU I<troff>."

"For example, GNU I<troff> would be installed as I<gtroff>."

"Viewer for\\ I<groff>\\ (and AT&T device-independent\\ I<troff>)\\ documents:"
--
Man page: groff.1
Issue:    I<\\%grn> → MR  \\%grn 1 \\%grn 1

"It is passed to E<.MR \\%soelim 1> and the output driver, and I<\\%grn> is "
"passed an B<-M> option with I<dir> as its argument."
--
Man page: groff.1
Issue 1:  I<\\%pic> → .MR \\%pic 1
Issue 2:  I<\\%troff> → .MR \\%troff 1

"Operate in unsafe mode: pass the B<-U> option to I<\\%pic> and I<\\%troff>."
--
Man page: groff.1
Issue:    cnumeric-expression → numeric-expression

"B<-r\\ >I<cnumeric-expression>"
--
Man page: groff.1
Issue 1:  I<roff> → .MR roff 7
Issue 2:  I<troff> → .MR \\%troff 1

"The architecture of the GNU I<roff> system follows that of other device-"
"independent I<roff> implementations, comprising preprocessors, macro "
"packages, output drivers (or \\[lq]postprocessors\\[rq]), a suite of "
"utilities, and the formatter I<\\%troff> at its heart."

"In GNU I<roff>, the page dimensions for the formatter I<\\%troff> and for "
"output devices are handled separately."

"GNU I<roff> extensions to the AT&T I<troff> language, a common subset of "
"I<roff> dialects extant today, are detailed in E<.MR groff_diff 7 .>"

"GNU I<roff> provides reimplementations of most preprocessors familiar to "
"users of AT&T I<troff>; these routinely have extended features and/or "
"require GNU I<troff> to format their output."

"A preprocessor unique to GNU I<roff> is E<.MR preconv 1 ,> which converts "
"various input encodings to something GNU I<troff> can understand."

"The GNU I<roff> system implements most well-known macro packages for AT&T "
"I<troff> in a compatible way and extends them."

"The command-line option B<-C> switches I<\\%troff> into I<compatibility "
"mode>, which tries to emulate AT&T I<troff> as closely as is practical to "
"enable the formatting of documents written for the older system."

"GNU I<roff> can be configured at compile time to apply a prefix to the names "
"of the programs it provides that had a counterpart in AT&T I<troff>, so that "
"name collisions are avoided at run time."
--
Man page: groff.1
Issue:    I<sed> → .MR sed 1

"We used a I<sed> command only to eliminate the 65 blank lines that would "
"otherwise flood the terminal screen."
--
Man page: groff.1
Issue 1:  I<nroff> → .MR nroff 1
Issue 2:  I<troff> → .Mr troff 1

"These have one- or two-letter names arising from intense practices of naming "
"economy in early Unix culture, a laconic approach that led to many of the "
"packages being identified in general usage with the I<nroff> and I<troff> "
"option letter used to invoke them, sometimes to punning effect, as with "
"\\[lq]man\\[rq] (short for \\[lq]manual\\[rq]), and even with the option "
"dash, as in the case of the I<s> package, much better known as I<ms> or even "
"I<-ms>."

"It provides the features of the AT&T I<troff> and I<nroff> programs as well "
"as many extensions."
--
Man page: groff.1
Issue:    Use colon at end of line?
"An output device may be any of the following."

"Once a E<.MR man 1> librarian program has located a man page, it may execute "
"a I<groff> command much like the following."
--
Man page: groff.1
Issue:    ISO 646 1991:IRV  → ISO/IEC 646:1991  (what des IRV stand for?)

"for terminals using the ISO 646 1991:IRV character set and encoding, also "
"known as US-ASCII."
--
Man page: groff.1
Issue:    ISO → ISO/IEC
"for terminals using the ISO Latin-1 (ISO 8859-1)  character set and encoding."

"for terminals using the ISO 10646 (\\[lq]Unicode\\[rq]) character set in "
"UTF-8 encoding."

"Conversely, the output device B<cp1047> is not available on systems based on "
"the ISO\\ 646 or ISO\\ 8859 character encoding standards."
--
Man page: groff.1
Issue:    I<\\%gxditview> → .MR \\%gxditview 1

"for previewing with I<\\%gxditview> using 75 dpi resolution and a 10-point "
"base type size."

"for previewing with I<\\%gxditview> using 75 dpi resolution and a 12-point "
"base type size."

"for previewing with I<\\%gxditview> using 100 dpi resolution and a 10-point "
"base type size."

"for previewing with I<\\%gxditview> using 100 dpi resolution and a 12-point "
"base type size."

"The B<-X> option overrides this selection, causing I<\\%gxditview> to serve "
"as the output driver."
--
Man page: groff.1
Issue:    I<\\%afmtodit> → .MR \\%afmtodit 1

"translates a PostScript Type\\ 1 font in PFB (Printer Font Binary)  format "
"to PFA (Printer Font ASCII), which can then be interpreted by I<\\%afmtodit>."
--
Man page: groff.1
Issue 1:  I<troff> → .MR troff 1
Issue 2:  I<nroff> → .MR nroff 1
Issue 3:  I<\\%soelim> → .MR soelim 1
Issue 4:  I<\\%indxbib> → .MR indxbib 1
Issue 5:  I<\\%lookbib> → .MR lookbib 1

"Besides I<troff>, the prefix applies to the formatter I<nroff>; the "
"preprocessors I<eqn>, I<grn>, I<pic>, I<\\%refer>, I<tbl>, and I<\\%soelim>; "
"and the utilities I<\\%indxbib> and I<\\%lookbib>."
--
Man page: groff.1
Issue:    I<preconv>(1) → .MR preconv 1

"The value of this variable is passed to the I<preconv>(1)  preprocessor's B<-"
"e> option to select the character encoding of input files."

"If set but empty, I<groff> calls I<preconv> without an B<-e> option."
--
Man page: soelim.1
Issue:    I<\\%soelim> → B<soelim>

"In the absence of I<input-file> arguments, I<\\%soelim> reads the standard "
"input stream."

"Any other escape sequence in I<macro-file>, including \\[lq]B<\\[rs]"
"[rs]>\\[rq], prevents I<\\%soelim> from replacing the source request."

"The dot must be at the beginning of a line and must be followed by "
"\\[lq]B<so>\\[rq] without intervening spaces or tabs for I<\\%soelim> to "
"handle it."

"This convention allows source requests to be \\[lq]protected\\[rq] from "
"processing by I<\\%soelim>, for instance as part of macro definitions or "
"\\[lq]B<if>\\[rq] requests."
--
Man page: soelim.1
Issue:    I<roff> → .MR roff 7

"I<soelim> was designed to handle situations where the target of a I<roff> "
"source request requires a preprocessor such as E<.MR \\%eqn 1 ,> E<.MR \\"
"%pic 1 ,> E<.MR \\%refer 1 ,> or E<.MR \\%tbl 1 .>"
--
Man page: soelim.1
Issue:    I<\\%troff> → .MR troff 1

"That is, files sourced with \\[lq]B<so>\\[rq] are normally read I<only> by "
"the formatter, I<\\%troff>."
--
Man page: soelim.1
Issue 1:  I<\\%soelim> → B<\\%soelim>
Issue 2:  I<\\%troff> → .MR \\%troff 1

"I<\\%soelim> is I<not> required for I<\\%troff> to source files."

Helge Kreutzmann <kreutzm>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by schwarze (Posted a comment)
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by barx (Updated the item)
  • -email is unavailable- added by kreutzm (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2025-06-24 gbranden Severity3 - Normal 2 - Minor
        Summarymanpage-10n project: issues in man pages man pages should refer to "ISO/IEC" standards
    2024-09-14 gbranden StatusFixed None
        Assigned togbranden None
        Open/ClosedClosed Open
        Planned Release1.24.0 None
    2024-09-12 gbranden Assigned toNone gbranden
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.24.0
    2024-09-12 gbranden StatusNone Fixed
    2024-09-11 gbranden SummaryIssues in man pages manpage-10n project: issues in man pages
    2024-08-19 barx CategoryNone General
        Item GroupNone Documentation

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code