original submission:

> Issue B: "groff -a" ("approximate output") is not consistent
> with the foregoing.

I'm not sure that's an accurate assessment.  The typeset output has the "foo" and the "baz" overstruck.  Terminal output, which can't overstrike, has to choose which of those strings to represent.  The decision made by -Tascii and -a are different, but they're both consistent with the typeset output within the limitations of a terminal.

If you want to argue that -Tascii and -a should make the same decision about which overstruck character to favor, this isn't an issue with .cf per se, but with anything that involves overstruck characters.

$ echo "a\o'bc'd" | groff -Tascii | cat -s
acd

$ echo "a\o'bc'd" | groff -a
<beginning of page>
ad

This -a output is arguably worse than your example because it displays neither of the overstruck characters, whereas -Tascii does choose one of them to display.  But in any case it is certainly unrelated to .cf.

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