Dear Maintainer,

   * What led up to the situation?

man zip (run as root)

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

with

export MANOPT=-E latin1 --no-hyphenation --no-justification --warnings=w
export MAN_KEEP_STDERR=yes

man zip > /dev/null

   * What was the outcome of this action?

troff:<standard input>:175: warning: cannot select font 'C'
...

   * What outcome did you expect instead?

No warnings.

-.-.

File "/etc/groff/man.local" needs a font transformation

.if n .ftr C R

In my opinion, this bug should be reassigned to the zip package.

Also, the correct term is "font translation", not "font transformation".

https://www.gnu.org/software/groff/manual/groff.html.node/Selecting-Fonts.html

At 2023-08-07T22:11:43+0000, Bjarni Ingi Gislason wrote:

Can reproduce.  This warning occurs many times, along with two others.

troff:zip.1:1675: warning: cannot select font 'N'
troff:zip.1:2636: warning: escape character ignored before 'i'

These two appear to be due to typos.

These messages arise due to errors in the page sources; the formatter is
unable to do what is being asked of it.

Colin Watson rejected this idea when Python docutils-generated man pages
exhibited the same problem.  This issue has now been fixed upstream in
python-docutils--the right place, in my opinion--and uploaded to Debian.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041809

zip(1) appears to have been composed directly by a human.  The page is
(strictly speaking) buggy, and use of the `\fC` escape sequence is not
portable across *roff implementations.  It is also ineffectual on
terminal output devices regardless of implementation.

There are a number of related problems here.

* It's impossible to change font family or type size in an nroff
  document.  Nevertheless, it is attempted commonly enough that GNU
  troff (and all other troffs I know of) silently ignore such attempts.
* Not all troffs even support the _concept_ of "font families"; you will
  not find it in Ossanna troff or Kernighan troff.
* Portable man pages must use only fonts named `R`, `I`, and `B`.  It is
  consequently better to use man(7)'s facilities for switching fonts.
* Even on typesetting devices, a font named `C` is not guaranteed to
  exist.  As far as I can tell from my research over the years, this
  font name was never supported by the troff in BSD Unix until it
  replaced its AT&T troff with GNU troff.
* AT&T device-independent troff, in lines of descent from Kernighan
  troff (ca. 1980), _sometimes_ supported a font named `C`.  Sometimes
  it was called `CW` instead.  Sometimes both were available.  Sometimes
  it wasn't available at all.
* There is no portable interface for testing the availability of a font
  in the output device.  GNU troff supports `.if F` for this purpose;
  AT&T troff and at least some of its descendants do not.

It appears to me that in most or all cases, zip(1) uses this 'C' font
mark up literal input, like examples of command-line usage, on their own
output lines.  That's good, because it suggests that the page can easily
migrate to the EX/EE man(7) extension, first developed in Research Ninth
Edition Unix (1986) and adopted by groff in 2007-2009.

To retain portability, since Info-ZIP likely wants to retain support for
a huge variety of systems, the page could take the approach recently
adopted by lexgrog(1) in the man-db project.

It looks like the upstream package hasn't been updated in 15 years.  I'm
happy to prepare some patches to improve its man pages for the Debian
package.  It looks like most of the corrections relevant to this bug
report can be straightforwardly automated with sed(1).

I'm also happy to contribute some further correctness and portability
issues to the page per groff_man_style(7).

Let me know.

Regards,
Branden

Control: reassign -1 zip

Agreed.  Reassigning there.