[bug #65052] [troff] `cf` behavioral anomalies

[G. Branden Robinson]

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/