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
Description: PGP signature
