Follow-up Comment #3, bug #63133 (project groff): [comment #2 comment #2:] > Long story short, the `.C` register didn't work for some of the use cases people had for it, including the one seen above. Yep. The interaction between compatibility mode and '.C' is kind of tricky ... when compatibility mode is on, it needs to be interpolated using the '\n(.C' syntax, because the '\n[.C]' syntax isn't "compatible":
$ printf '.cp 0\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null .C = 0 $ printf '.cp 1\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null .C = troff: <standard input>:2: warning: number register '[' not defined 0.C] $ printf '.cp 1\n.tm .C = \\n(.C\n' | groff -ww > /dev/null .C = 1 Interaction with the '.do' request compounds the trickiness: $ printf '.cp 1\n.do tm .C = \\n[.C]\n' | groff -ww > /dev/null .C = 0 $ printf '.cp 1\n.do tm .C = \\n(.C\n' | groff -ww > /dev/null .C = 0 It appears that the '.do' takes effect *before* the remainder of the request line, (and in particular, the '\n(.C' evaluation), is parsed. Thus, within the scope of '.do', '\n(.C' must *always* evaluate to zero. This isn't made particularly clear, in the relevant groff documentation. > 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. Or ... perhaps more likely ... few people use groff directly, to render manpages, and even those who may have done so didn't think to add the '-ww' option? > > 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 Yes; it's what is installed by default, by the Manjaro derivative of Arch Linux, (which is my current distro of choice). > (else you wouldn't get the diagnostic message, which also hasn't been worded that way since before commit 31e8ff9daf on 30 June 2021. Fair enough. I noticed it when formatting up-to-date pdfroff.1.man with similarly up-to-date pdfroff, and with '-ww' in effect, per this ticket, but underpinned by the system-native groff installation. > 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. I no longer feel comfortable committing directly to the groff repo, following the debacle when you deleted a published branch ... > Would you prefer to make your OSDN the official pdfmark resource? so yes, I would prefer to keep control of my own development tree. > I don't think it would do anyone any good for contrib/pdfmark to bit-rot in groff's contrib. Agreed. I have, indeed, added significant new content to pdfmark.pdf, (via pdfmark.ms), and some pdfroff enhancements, which are not now included in groff's contrib/pdfmark tree. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63133> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
