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

[Dave]

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/