[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: G. Branden Robinson
Subject: [bug #63133] [pdfroff] throws warning on any document if -ww given
Date: Tue, 21 Feb 2023 13:10:13 -0500 (EST)

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

[comment #3 comment #3:]
> [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.

I have tried to clarify it for groff 1.23.




> > 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'

The reason I noticed it is because when batch-rendering man pages, some got
formatted incorrectly because the incorrect saved value of compatibility mode
was used.  That would generally be much more noticeable than a warning which
is off by default and even if enabled by the user, is typically discarded by
man(1), as you note.

> > 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 ...

For which I apologized, but if you object to published branches being deleted
even _with_ notice, then, yes, it seems your development preferences and the
groff project's
<https://lists.gnu.org/archive/html/groff/2021-11/msg00015.html> have diverged
and will do so again.  (After about a year, I deleted the "tmp-mail-fail"
branch that I created to work around groff-commit reflector problems.)

> > 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.

Okay.  I will update groff's copy of pdfroff(1) shortly to point to your site,
advising users of the move.  I will also withdraw the contrib/pdfmark
directory itself in the next development cycle--I feel it is too disruptive a
change at present (on our 3rd release candidate for 1.23.0.)  (The man page
update can go in before final, of course.)

Thank you for your contributions.


Reply to this item at:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]