Re: Unintentional additional space after rfc1345 escape sequences?

"G. Branden Robinson" <[email protected]> Wed, 17 Dec 2025 13:20:13 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20251217192013.d5pqansw53dojhgk@illithid>
Hi Alexis,

At 2025-12-05T17:51:59+0100, Alexis (surryhill) wrote:
> when using escape sequences from contrib/rfc1345/rfc1345.tmac,
> additional spaces appear after the character for me, which
> seems unintentional.
> 
> Given the following example:
> 
>   echo '\(Fo\(mc\(Fc vs. \(Fo\[My]\(Fc' | groff -mrfc1345 -Tutf8 | head -1
>   «µ» vs. «µ    »
> 
> I'd rather expect the following than the above:
>   «µ» vs. «µ»

Can reproduce.

$ printf '\\(Fo\\(mc\\(Fc vs. \\(Fo\\[My]\\(Fc\n' \
  | groff -mrfc1345 -Tutf8 | head -1
«µ» vs. «µ    »

> Possibly the issue lies elsewhere in groff, yet removing the
> additional spaces before the comment at the end of each character
> definition in rfc1345.tmac also removes the additional spaces from the
> output, e.g.:
> 
>   sed -i -Ee 's/\]  +\\/]\\/' contrib/rfc1345/rfc1345.tmac

No, it's a real problem and you correctly diagnosed the cause.

Requests that read the rest of the input line into an argument[1] are
susceptible to this undesired behavior when people writing comments
attempt to virtuously give those comments columnar alignment by adding
spaces.  The problem is that they put the spaces _before_ the comment
escape sequence instead of after.

(An equivalent harmless approach is to put the comment escape sequence
in _both_ places.)

So this:

.char \[NO] \[u00AC]    \" NOT SIGN

...should have been this...

.char \[NO] \[u00AC]\"     NOT SIGN

...or this.

.char \[NO] \[u00AC]\"  \" NOT SIGN

There have long been several such requests, and in groff 1.24 there will
be more.[1]

String definitions (the `ds` and `as` requests, among others in GNU
troff) work the same way and one has been able to make similar grief for
oneself by commenting this way, going back to Ossanna troff in the '70s.

Please file a Savannah ticket for this.  A patch would be cool, too.

I'll check our documentation to ensure that the `char` request is
documented as "reading [its second argument] to the end of the line in
copy mode", which as I recall is my stock phrase for this behavior.

Regards,
Branden

[1] NEWS:

VERSION next
============

Noteworthy incompatible changes
-------------------------------

*  If your roff(7) documents follow any of the requests `cf`, `hpf`,
   `hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `so`, `soquiet`, or
   `trf` with a comment after their file name argument, and did not
   place that comment immediately after the file name, you are likely to
   get a diagnostic message resembling the following.

    warning: cannot open macro file 'e.tmac ': No such file or directory

   Or, less likely, the formatter will open the wrong file, one with
   spaces at the end of its name.  That is because these requests are
   now able to process file names containing space characters.  (This
   change also makes the request syntax consistent with that of `ds`,
   `as`, and others.)  A quick fix is to place the comment escape
   sequence as early as possible.  For example, we would change:

     .mso e.tmac \" Load Eric Allman's package.

   to:

     .mso e.tmac\" Load Eric Allman's package.

   to tell the formatter to load the "e.tmac" file rather than
   "e.tmac ".  See the items below for further details.

*  If your roff(7) documents specify a file name that starts with a
   neutral double quote (") to any of the requests `cf`, `hpf`,
   `hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `so`, `soquiet`, or
   `trf`, you are likely to get a diagnostic message, or the formatter
   will open a file of the same name except for the leading neutral
   double quote.  That is because these requests are now able to process
   file names containing leading space characters.  (This change also
   makes the request syntax consistent with that of `ds`, `as`, and
   others.)  The solution is to add an additional neutral double quote
   to the start of the file name argument.  For example, we would
   change:

     .so "5150".lrc

   to:

     .so ""5150".lrc

   to tell the formatter to read a file named '"5150".lrc', where the
   neutral single quotes bracket the file name.
signature.asc (application/pgp-signature, 833 B)