[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #58958] undocumented (or just broken) inability of .char to map to

From: Dave
Subject: [bug #58958] undocumented (or just broken) inability of .char to map to \:
Date: Mon, 13 Jun 2022 21:01:26 -0400 (EDT)

Follow-up Comment #6, bug #58958 (project groff):

[comment #5 comment #5:]
> In comment #3, the '-z' should have been '-Z'.

OK, now I can replicate your "groff" results.  I get identical -Z output
whether I use groff 1.22.4 or a recent build.

nroff as shipped lacks the -Z option, so that one still fails.

> I now look at the space before the end of the output line to be a bug
> in the processing of the escape sequence '\:' in such a position.

Is this space perhaps due to the newline "echo" appends by default?  Consider
the output of:

diff <(echo '\:' | groff -Z) <(echo -n '\:' | groff -Z)

(Notably, grops and gropdf produce identical output for both sets of
intermediate output, so the "difference" here is effectively only internal.)

> The term for such "characters" (an element in a set) is "format
> effectors".

Then I amend my original bug report to say, ".char being unable to map
something to a format effector, or at least to this particular format
effector, is a bug either in the implementation, or in the lack of
documentation of the restriction."


Reply to this item at:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]