bugGNU roff - Bugs: bug #65052, [troff] `cf` behavioral anomalies


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

Submitter:  G. Branden Robinson <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 Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Tue 19 Dec 2023 11:35:00 PM UTC, comment #2: 

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

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

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.

Dave <barx>
Group Member
Tue 19 Dec 2023 06:19:17 PM UTC, comment #1: 

The test you are using is a bit strange. The only proper use for these commands are to include files which are independently movement agnostic. What I mean is they contain grout which does something completely independent of the document which calls it. Think of a set of grout commands which moves to one corner and draws a logo.

The reason is because groff and whichever output driver is used must maintain a consistent view of the current X/Y position, i.e. where the next glyph or graphics command will start. If you send "tbaz" to the output driver its notion of the current X position will be after the "z" but groff, which has not seen the text "baz", will still think the current X position is where the "b" starts. This way there be dragons, (and overwriting!).

For this reason, needing to maintain synchronicity with the output driver, these commands are not very useful. I suspect they are only really meant for passing stuff like postscript code to grops, but this can be easily achieved with a \Y'' call.

Issue C/D

This is analogous to using \!, it does not cause a break so gets output immediately, before whatever has been input for the current line, if you want to retain proper sequence in the grout you need a .fl before the \!. The reason baz is missing will become clear if you don't send stderr to /dev/null.

Deri James <deri>
Group Member
Tue 19 Dec 2023 03:58:35 PM UTC, original submission:  

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

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
.cf ATTIC/transparency.grout

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:



That is not what I see.

Issue A: "foo" gets overstruck.

$ groff -Tascii ATTIC/try-cf.roff | cat -s

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

$ groff -a -Tascii ATTIC/try-cf.roff
<beginning of page>

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.



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
x font 1 R
n40 0
x trailer
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.


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

G. Branden Robinson <gbranden>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by deri (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-6207.
    Corresponding source code