[bug #64594] [troff] "warning: cannot select font 'C'"

[G. Branden Robinson]

Update of bug #64594 (project groff):

                Category:                    None => Core                   
              Item Group:                    None => Warning/Suspicious
behaviour
                  Status:                    None => Need Info              
             Assigned to:                    None => gbranden               
                 Summary: "warning: cannot select font 'C'" => [troff]
"warning: cannot select font 'C'"

    _______________________________________________________

Follow-up Comment #1:

[comment #0 original submission:]
> Hi. The following man page:
[...]
> Gives warnings with `man -l example.1 | grep warn`
> 

> troff:<standard input>:5: warning: cannot select font 'CB'
> troff:<standard input>:23: warning: cannot select font 'C'


> 
> It's unclear to me whether this is an issue in groff or pandoc. I also
reported the issue to pandoc https://github.com/jgm/pandoc/issues/9020

It has also been reported to Debian...

https://bugs.debian.org/1041809
https://bugs.debian.org/1043256

...to go-md2man...

https://github.com/cpuguy83/go-md2man/issues/99

...and to (Python) docutils, where a fix has been applied.

https://sourceforge.net/p/docutils/patches/205/

Quoting jgm at Pandoc issue #9020:

> Looking quickly at the changelog for 1.23, I didn't see anything relevant

The ChangeLog file for 1.23.0 is gigantic, and one could be forgiven for
missing this item.  What happened is that a lot of font loading failures that
were silent before now warn.  There were a few changes in this area.  Here's
one.

https://git.savannah.gnu.org/cgit/groff.git/commit/?id=87efb8ff373d5cf3b92be9d21445a80b264fa961

The main issue is that 'C' is not a _groff_ font name and never has been. 
(One does encounter it, for some output devices, on AT&T/DWB _troff_, from
which Plan 9 and Solaris _troff_s are descended.)

'C' has long been the name of a _groff_ font _family_. 
[https://www.gnu.org/software/groff/manual/groff.html.node/Using-Fonts.html
Here's some background from the GNU troff manual].


> .\" Automatically generated by Pandoc 3.1.6.1
> .\"
> .\" Define V font for inline verbatim, using C font in formats
> .\" that render this, and otherwise B font.
> .ie "\f[CB]x\f[]"x" \{\
> . ftr V B
> . ftr VI BI
> . ftr VB B
> . ftr VBI BI
> .\}
> .el \{\
> . ftr V CR
> . ftr VI CI
> . ftr VB CB
> . ftr VBI CBI
> .\}


My concern with the foregoing is that it is not portable.  The \f[] style of
escape sequence is a _groff_ism.  Heirloom Doctools _troff_ and _mandoc_ also
support it.  But if those two and _groff_ are the only formatters you care to
support, these font remappings with the `ftr` request should not even be
necessary; _groff_'s "an.tmac" file, which implements the _man_(7) macro
package, takes care of this, and Heirloom and _mandoc_ should do similarly.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?h=1.23.0#n1300

The foregoing tests for _nroff_ mode.  It remaps requests for fonts from the
Courier family to their ordinary ("un-familied") style names. 
(Terminals--_nroff_ devices--don't support font families.)

The _pandoc_ code appears to want to use bold instead; the comment suggests
that this is for visibility when rendering inline.  That's okay.  But it does
mean the logic can be simplified.


.\" Automatically generated by Pandoc IN AN IMAGINED FUTURE
.\"
.\" Remap Courier family to bold styles on terminals for
.\" visibility inline.
.if \n(.g .if n \{\
. do ftr CR B
. do ftr CI BI
. do ftr CB B
. do ftr CBI BI
.\}


Half as much logic, and safe in _groff_'s AT&T
[https://www.gnu.org/software/groff/manual/groff.html.node/Compatibility-Mode.html
compatibility mode] in the bargain.

If you're not targeting formatters outside the trio of _groff_/Heirloom
Doctools/_mandoc_, you can drop the '.if \n(.g ' from the foregoing.  (It
tests a Boolean-valued register that proclaims compatibility with _groff_
extensions to _troff_.)


> .TH "" "" "" "" ""
> .hy


This hyphenation request doesn't do what you want, on *any* _troff_.

"Set automatic hyphenation mode to mode, an integer encoding conditions for
hyphenation; if omitted, ‘1’ is implied."
([https://www.gnu.org/software/groff/manual/groff.html.node/Manipulating-Hyphenation.html
GNU troff Manual)

The correct hyphenation mode for AT&T _troff_ was 14; for _groff_ it is 4. 
The difference is due to the different hyphenation systems in use.

I recommend not ever calling the `hy` or `nh` requests in man pages.  However
I do have a [https://savannah.gnu.org/bugs/?63635 feature] in mind for _groff_
1.24 that will make doing so recoverable rather than destructive.


> .PP
> Paragraph with \f[V]inline code\f[R]


I'd start emitting \f[CR] and similar here instead of \f[V].


> .IP
> .nf
> \f[C]
> Code block line 1
> Code block line 2
> Code block line 3
> \f[R]
> .fi


This is the _exact_ issue Python docutils had, and I recommend the same
solution.  Use the `EX`/`EE` extension macros from Ninth Edition Unix (1986),
which was reintroduced to the world by _groff_ 1.20 in 2009.

In [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049968;msg=10 that
ticket] I have an inline implementation (slightly simplified from _groff_'s
_an-ext.tmac_ file) that you can use.  But again, if you're targeting only
_groff_, Heirloom Doctools, and _mandoc_, you don't even need that; all three
support the `EX` and `EE` macros out of the box.

To conclude, I don't think this is a _groff_ bug, but it's one of the most
noted things about the _groff_ 1.23.0 release, so I will set this ticket's
state to "Need Info" to gather feedback for a while.

And I do appreciate some feedback.


    _______________________________________________________

Reply to this item at:

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

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