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 <[email protected]> > 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/
