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

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

G. Branden Robinson <gbranden>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

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