[bug #63133] [pdfroff] throws warning on any document if -ww given

[G. Branden Robinson]

Follow-up Comment #2, bug #63133 (project groff):

Hi Keith,

[comment #1 comment #1:]
> Obviously, since your test case doesn't load any PDF related macro sets,
pdfhref is not going to be defined.

It's not _quite_ obvious to me; I think macros that bind tightly to output
driver features should probably be declared in a macro file corresponding to
the output device.

That is what troffrc has expected for a long time.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/troffrc?h=1.22.3.real#n32

I'll grant that the absence of a 'pdf' out device for a long time in groff
made such a coupling less straightforward.  For a workflow which uses groff to
produce another output format (PostScript) and only converts to PDF after
groff has finished with a document, I think your requirement of some
pdfhref-providing macro file is more easily motivated.
 
> I do appreciate the minimalism of your test case; with the addition of the
'--keep-temporary-files' option, it becomes trivially easy to identify the
source of the spurious 'pdfhref' reference.  However, since it runs pdfroff,
with no attempt to incorporate *any* PDF features, does it really provide a
compelling incentive to pursue the issue?  I hardly think so, but I *can* find
such an incentive in the '%.pdf:%.man' Makefile.in rule, in my own
groff-pdfmark development fork
<https://osdn.net/users/keith/pf/groff-pdfmark/scm/blobs/tip/Makefile.in>. 
Specifically, (if I edit the generated Makefile, to remove the
'--no-reference-dictionary' and '--no-toc-relocation' options, the former of
which prevents the issue from arising, but then requires the latter to avoid
duplication of output), when I invoke this, I see:
> 
> $ make -C wip/build/ pdfroff.1.pdf MAN2PDF_FLAGS=-ww
> make: Entering directory '/home/keith/projects/groff-pdfmark/wip/build'
> /usr/bin/sed -e 's!@VERSION@!1.23.0!' -e 's!@MDATE@!20 February 2023!' -e
's!@PDFDOCDIR@!/usr/local/share/doc/!' -e 's!@MAN\([1-9]\)EXT@!\1!g'
../../pdfroff.1.man | GROFF_TMAC_PATH=../../tmac /bin/sh ./pdfroff -man -ww >
pdfroff.1.pdf
> troff: ./pdfroff-jfeZdKTQvb/pdf19949.cmp:1: warning: macro 'pdfhref' not
defined
> troff: <standard input>:30: warning: number register '.cp' not defined
> make: Leaving directory '/home/keith/projects/groff-pdfmark/wip/build'
> 
> This does, indeed, reproduce the issue which you report, (and I do have a
practical solution, *without* requiring the '--no-reference-dictionary'
option).

Cool!

>  However, it also reveals a more insidious issue, (viz. the reference to
undefined '.cp' number register), which appears to be endemic among the entire
corpus of manpage sources, throughout the groff code base; it appears to have
been introduced by:
> 
> $ hg annotate src/roff/groff/groff.1.man
> ...
> 3963: .\" Save and disable compatibility mode (for, e.g., Solaris 10/11).
> 3963: .do nr *groff_groff_1_man_C \n[.cp]
> 3963: .cp 0
> ...
> 
> $ hg log -r 3963
> changeset:   3963:01c8e28fa4bd
> user:        G. Branden Robinson <g.branden.robinson@gmail.com>
> date:        Sun Oct 18 22:56:32 2020 +1100
> summary:     man pages: Make preambles consistent.
> 

Yes, that relates to one of the items in the NEWS file.


o A new read-only register `.cp` is implemented.  Within a `do` request,
  "\n[.cp]" holds the saved value of compatibility mode.  See
  groff_diff(7) or the groff Texinfo manual for rationale, use case, and
  example.


Long story short, the `.C` register didn't work for some of the use cases
people had for it, including the one seen above.  This went unnoticed for a
long time, I think, because relatively few people tried to render many groff
man pages in series using a single invocation of the formatter.

> Please note that this wider issue is not even related to pdfroff:
> 
> $ groff -ww -man src/roff/groff/groff.1 > /dev/null
> troff: src/roff/groff/groff.1:25: warning: number register '.cp' not
defined
> 
> Does this merit its own bug report?

I don't think so.  It was a deliberate feature change.  I infer that you're
running the above commands using groff 1.22.4 (else you wouldn't get the
diagnostic message, which also hasn't been worded that way since before commit
31e8ff9daf on 30 June 2021.

On another subject:

> in my own groff-pdfmark development fork
<https://osdn.net/users/keith/pf/groff-pdfmark/scm/blobs/tip/Makefile.in>.

In bug #63590, you expressed disinterest in maintaining pdfmark in the groff
source tree.

Would you prefer to make your OSDN the official pdfmark resource?  I don't
think it would do anyone any good for contrib/pdfmark to bit-rot in groff's
contrib.

Regards,
Branden


    _______________________________________________________

Reply to this item at:

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

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