URL:
<https://savannah.gnu.org/bugs/?65052>
Summary: [troff] `cf` behavioral anomalies
Group: GNU roff
Submitter: gbranden
Submitted: Tue 19 Dec 2023 03:58:35 PM UTC
Category: Core
Severity: 3 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Tue 19 Dec 2023 03:58:35 PM UTC By: G. Branden Robinson <gbranden>
I perceive some weirdness here. These are either bugs or need to be
documented.
Consider first an input file used for "transparent throughput". (Basically,
this means a file already in device-independent output format.)
$ cat ATTIC/transparency.grout
tbaz
The foregoing puts the text "bar" on the output with no break or drawing
position movement before or after.
Here is an input file using it.
$ cat ATTIC/try-cf.roff
foobar
.cf ATTIC/transparency.grout
qux
Of `cf`, CSTR #54 (1992) says only:
"Copy contents of file _filename_ to output, completely unprocessed. The file
is assumed to contain something meaningful to the subsequent process."
I would therefore expect the input above to produce a document containing
"foobar", a line break (this is implied by invoking `cf` with the normal
control character--see below), and then "bazqux".
In other words:
Expected:
foobar
bazqux
That is not what I see.
Issue A: "foo" gets overstruck.
$ groff -Tascii ATTIC/try-cf.roff | cat -s
bazbar
qux
Issue B: "groff -a" ("approximate output") is not consistent with the
foregoing.
$ groff -a -Tascii ATTIC/try-cf.roff
<beginning of page>
foobar
qux
If we invoke the `cf` request with the no-break character, _groff_ intends
([https://git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.23.0#n7684
per its source code]) to not break the output line before interpolating the
file contents.
Expected:
foobarbazqux
Issue C: This goes bizarrely wrong.
$ groff -Tascii ATTIC/try-cf-no-break.roff | cat -s
grotty:<standard input>:7: error: invalid font position '-1'
grotty:<standard input>:7: error: invalid font position '-1'
grotty:<standard input>:7: error: invalid font position '-1'
foobar qux
First let's consider the diagnostics.
Inspecting the "grout", we see that the file contents are emitting before font
setup for the output device is complete.
$ groff -Z -Tascii ATTIC/try-cf-no-break.roff | cat -s
x T ascii
x res 240 24 40
x init
p1
V0
H0
tbaz
x font 1 R
f1
s10
V40
H0
md
DFd
tfoobar
wh24
tqux
n40 0
x trailer
V2640
x stop
PostScript has an analogous problem, so I suspect no conditional nroff-mode
involvement.
Arguably, this not a bug; _groff_ doesn't send "x font" commands to the output
until it has a glyph to format, and the font data for a glyph are part of its
"node", so design-wise I foresee it being difficult or even unwise to "fix"
this. Instead, our documentation should advise users that if they mean to
interpolate files into GNU _troff_ output, they are responsible for
appropriate setup of the output device.
Issue D:
Returning to the actual formatted output, the word "baz" has gone missing in
the output.
+verbatim+
$ groff -Tascii ATTIC/try-cf-no-break.roff 2>/dev/null | cat -s
foobar qux
`trf` has similar problems, but this is enough to bite off for the time being.
They two requests don't share much code, unfortunately, so its bugs may be
independent.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65052>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
