[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:
<https://savannah.gnu.org/bugs/?58958>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/