bugGNU troff - Bugs: bug #58962, Latin-1 NO-BREAK SPACE does not...

 
 

bug #58962: Latin-1 NO-BREAK SPACE does not behave as documented

Submitted by:  Dave <barx>
Submitted on:  Sat 15 Aug 2020 05:25:30 PM UTC  
 
Category:  Core Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sat 05 Jun 2021 10:59:12 AM UTC, comment #1: 

original submission:

> groff(7) is less clear, saying that the test 's1's2' is "True if string s1
> is identical to string s2," which implies it's comparing input strings.


I see that commit 356bc65d has remedied this.

The prior unclear wording seems to originate in setion 16 of CSTR #54.

Dave <barx>
Project Member
Sat 15 Aug 2020 05:25:30 PM UTC, original submission:  

(Another bug report spawned from the discovery process of bug #58930.)

Quoth groff_char(7): "the ISO latin1 no-break space is mapped to `\~', the stretchable space character."

An eminently sensible mapping.  Oh, if only it were so.

In fact, the Latin-1 no-break space (character 160 decimal, A0 hex):

  • behaves the same as "\ ", the nonstretchable nonbreaking space character
  • matches neither "\ " nor "\~" in an output-equivalency conditional

Examining these in detail:

Behavior

Consider an input file with one instance of the string "<>", representing a nonbreaking space.  sed can convert this string to the various types of nonbreaking space under consideration (the two escapes and the raw Latin-1 character), and the typeset results compared by seeing which ones produce identical PostScript output.

$ cat t0
Lorem ipsum dolor sit amet, consectetur<>adipiscing elit, sed
do eiusmod tempor incididunt ut labore et dolore magna aliqua.
$ # Baseline test, for escapes expected to be different:
$ diff <(sed 's/<>/\\ /' t0 | groff) <(sed 's/<>/\\~/' t0 | groff) | wc
      8      68     403
$ # Output expected to be the same based on what the docs say:
$ diff <(sed 's/<>/\\~/' t0 | groff) <(sed 's/<>/\xA0/' t0 | groff) | wc
      8      68     403
$ # Output that turns out to be the same:
$ diff <(sed 's/<>/\\ /' t0 | groff) <(sed 's/<>/\xA0/' t0 | groff) | wc
      0       0       0
$

I'm filing this as "Incorrect behavio[u]r" rather than "Documentation" because I believe the documented behavior is more sensible than the actual behavior.  But that's a judgment call and open to debate.

Equivalency conditional

Either way, if Latin-1 A0 behaves the same as one of "\ " or "\~", the output-equivalency conditional operator (rendered as 'XXX'YYY' in the info manual, though a host of characters besides single quotes can be used) ought to recognize this.  But this operator claims the output of character A0 is equivalent to neither one (first observed in comment #2 of the aforementioned bug).

$ printf ".if '\xA0'\~' .tm equal\n" | groff
$ printf ".if '\xA0'\ ' .tm equal\n" | groff
$

(Granted, the documentation muddies what this operator is actually testing.  The info manual is clear about 'XXX'YYY', saying this is "True if the output produced by XXX is equal to the output produced by YYY."  But groff(7) is less clear, saying that the test 's1's2' is "True if string s1 is identical to string s2," which implies it's comparing input strings.  Were that the case, you'd expect both the above tests to be false... but you'd also expect '\[em]'\[u2014]' to be false, which it isn't.)

Dave <barx>
Project 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 barx (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-14 barx CategoryNone => Core

    Back to the top


    Powered by Savane 3.6