bugGNU roff - Bugs: bug #58958, undocumented (or just broken)...

 
 

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

Submitter:  Dave <barx>
Submitted:  Sat 15 Aug 2020 03:26:07 AM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Documentation Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 14 Jun 2022 01:01:26 AM UTC, comment #6: 

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

Dave <barx>
Group Member
Mon 13 Jun 2022 09:43:28 PM UTC, comment #5: 

In comment #3, the '-z' should have been '-Z'.

  The "test-nroff" script is the same as the "nroff" script,
but uses "test-groff" instead of "groff" (bug #55941).

  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.

  The escape sequence '\:' is not a (graphic) character in the most
common meaning.

  It might be described as an instruction (to format a typeset
output).

  The term for such "characters" (an element in a set) is "format
effectors".  Unicode has a category named "format characters" (Cf) for
these.

Bjarni Ingi Gislason <bjarniig>
Sun 12 Jun 2022 09:33:28 PM UTC, comment #4: 

comment #3:

> "\:" is not a character but a movement in the scope of "groff".


I'm not sure what this means.  \: is not documented as a movement.

> echo '\:' | test-groff -z


Using either 1.22.4 or 1.23.0.rc1.2295-f55d, I get no output from that command (as expected, since on its own \: should produce no movement or output).  Does your test-groff script do something beyond the stock one?

> echo '\:' | test-nroff -z


groff includes no test-nroff script, so I know this is your own customization.  Thus, this result is only meaningful if you post your script.

Dave <barx>
Group Member
Sun 22 Aug 2021 01:15:41 AM UTC, comment #3: 

"\:" is not a character but a movement in the scope of "groff".

echo '\:' | test-groff -z

x T ps
x res 72000 1 1
x init
p1
V12000
H72000
DFd
h2500
n12000 0
x trailer
V792000
x stop

echo '\:' | test-nroff -z

x T latin1
x res 240 24 40
x init
p1
V40
H0
DFd
H24
n40 0
x trailer
V2640
x stop


Bjarni Ingi Gislason <bjarniig>
Sat 15 Aug 2020 05:49:31 PM UTC, comment #2: 

comment #1:

> Alas, you didn't fix my typo.


Copy/paste failed to fix it.  I failed to notice it altogether.

Dave <barx>
Group Member
Sat 15 Aug 2020 03:47:59 AM UTC, comment #1: 

Alas, you didn't fix my typo.

> the exact character count of "\[u2000B]"


should have been

> the exact character count of "\[u200B]"

G. Branden Robinson <gbranden>
Group administrator
Sat 15 Aug 2020 03:26:07 AM UTC, original submission:  

(First mentioned as a side note in bug #58930, this problem is unrelated to that feature request and warrants its own report.)

.char \[u200B] \:

doesn't work.  .char being unable to map something to an escape, or at least to this particular escape, is a bug either in the implementation, or in the lack of documentation of the restriction.

Branden wrote the following in a follow-up comment:

It looks like the transform is just not happening:


.pl 1v
.char \[u200B] \:
.ds a \[u200B]
.length i \*a
\ni
8

.pl 1v
.ds a \[u200B]
.length i \*a
\ni
8

.pl 1v
.char a b
.ds a a
\*a
b


That unchanged length of 8, the exact character count of "\[u2000B]" is highly suspicious to me.

Dave <barx>
Group Member

 

(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 bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (Posted a comment)
  • -email is unavailable- added by barx (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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-08-15 gbranden StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code