bugGNU roff - Bugs: bug #62763, [hdtbl] man page should not...

 
 

bug #62763: [hdtbl] man page should not clobber special character names

Submitter:  Bjarni Ingi Gislason <bjarniig>
Submitted:  Thu 14 Jul 2022 12:10:52 AM UTC
   
 
Category:  Macro - others/general Severity:  3 - Normal
Item Group:  Warning/Suspicious behaviour Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 16 Jul 2022 08:25:54 AM UTC, comment #2: 

Oh, I get it.

I finally caught Bjarni using the UTF-8 encoding.  ;-)

With the `-Tascii` or `-Tlatin1` options, this problem does not happen.

And that in turn sniffs out the issue.

A groff character entry generally overrides any existing glyph definition of the same name in the currently available fonts (the one selected plus any special fonts).

The "ascii", "latin1", and "cp1047" output devices, like most of the others, all define an "or" glyph as an alias of the "|" glyph.

Character definitions are checked before the font glyph lists.  So if you remove such a character definition, troff will fall through to the fonts.

For the aforementioned 3 output devices, this works.

But for "utf8", it doesn't.  That is because the UTF-8 fonts have a degraded glyph repertoire as represented in their font descriptions.  devutf8/DESC has the "unicode" directive, which means that any font in use is assumed to have glyphs for all Unicode code points.  (devhtml/DESC does the same thing.)  A font for such a device can still have glyph definitions, which in that case override the default logic (which simply constructs a UTF-8 sequence or an HTML entity).

We should be able to test this theory by running the same experiment on one of the several typesetter devices that defines an "or" character in terms of drawing escape sequences.


$ ./build/test-groff -Tlbp -mandoc -t -z build/contrib/hdtbl/groff_hdtbl.7 ./EXPERIMENTS/if-c.groff build/man/groff_char.7
\[or] is NOT defined
\[lB] is defined
troff:build/man/groff_char.7:969: warning: special character 'or' not defined
troff:build/man/groff_char.7:1007: warning: special character '.j' not defined
troff:build/man/groff_char.7:1356: warning: special character 'braceex' not defined
troff:build/man/groff_char.7:1358: warning: special character 'bracketlefttp' not defined
...


I'm undecided as to whether there's anything wrong with this.

As Bjarni notes, the man page shouldn't be doing this in the first place.  I made the problem worse by removing the character definitions (commit 09687ec7c457d5a8508f3e30280081f467b21d39).  What I should have done was stash any existing character definitions in strings, and restore the character definitions using those strings at the end.

But what should really be done is for groff_hdtbl(7) to stop fooling around with character definitions at all.

 Some of the typesetter devices use `char`.

G. Branden Robinson <gbranden>
Group administrator
Sat 16 Jul 2022 08:08:04 AM UTC, comment #1: 

Something stranger is afoot here.

For one thing, I would not use the source versions of the man pages, which are not guaranteed to be valid, but their built versions.

For another, it's better to use groff_char(7) as the second man page to render because it exercises the entire special character repertoire.  Doing that, I found something interesting.

I don't get the diagnostic for the other characters that groff_hdtbl(7) redefines.  If I then insert a file in between to instrument the issue, the results are intriguing.


$ cat EXPERIMENTS/if-c.groff
.ie c \[or] .tm \[or] is defined
.el         .tm \[or] is NOT defined
.ie c \[lB] .tm \[lB] is defined
.el         .tm \[lB] is NOT defined
$ ./build/test-groff -mandoc -t -z build/contrib/hdtbl/groff_hdtbl.7 ./EXPERIMENTS/if-c.groff build/man/groff_char.7
\[or] is NOT defined
\[lB] is defined


So \[lB], \[rB], \[oq], and \[cq] have some kind of immunity to removal?  Spooky.

For the moment, I'm stumped on this one.

G. Branden Robinson <gbranden>
Group administrator
Thu 14 Jul 2022 12:10:52 AM UTC, original submission:  

Subject: [man] groff_hdtbl.1.man: do not redefine global character names

file: contrib/hdtbl/groff_hdtbl.1.man

  It contains redefined default (global) characters:

.char \[lB] \F[\n[.fam]]\f[R][
.char \[rB] \F[\n[.fam]]\f[R]]
.
.char \[or] \F[\n[.fam]]\f[R]\||\|
[...]
.
.char \[oq] \F[\n[.fam]]\f[R]\[oq]
.char \[cq] \F[\n[.fam]]\f[R]\[cq]

and their removal

.rchar \[lB]
.rchar \[rB]
.rchar \[or]
[...]
.rchar \[oq]
.rchar \[cq]

  Local names should be used.

  Otherwise these changes can affect the output of input files that are
processed after "groff_hdtbl.7.man" and "groff_hdtbl.7" with the same
command (batch execution).

Example

test-groff -mandoc -t -z contrib/hdtbl/groff_hdtbl.7.man  man/groff.7.man


Output:

[...]
troff: backtrace: file './man/groff.7.man':584
troff:./man/groff.7.man:584: warning: special character 'or' not defined

Bjarni Ingi Gislason <bjarniig>

 

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

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-07-16 gbranden CategoryGeneral Macro - others/general
        Summary[man] groff_hdtbl.1.man: do not redefine global character names [hdtbl] man page should not clobber special character names
    2022-07-16 gbranden StatusNeed Info Confirmed
    2022-07-16 gbranden StatusNone Need Info

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code