[bug #61401] [grohtml] doesn't remap \- in device escapes

[G. Branden Robinson]

URL:
  <https://savannah.gnu.org/bugs/?61401>

                 Summary: [grohtml] doesn't remap \- in device escapes
                 Project: GNU troff
            Submitted by: gbranden
            Submitted on: Sat 30 Oct 2021 01:57:35 AM UTC
                Category: Device grohtml
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: Need Info
                 Privacy: Public
             Assigned to: gbranden
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

This appears to be a result of the "use_charnames_in_special" directive, which
was designed to prevent this very sort of remapping.

However, this prevents typographically correct dashes from being included in
URLs.

Input:


$ cat EXPERIMENTS/dash-uri.man 
.TH foo 1 2021-10-30 "groff test suite"
.SH Name
foo \- a command with a very short name
.SH Description
Everything you want to know is in
.MR foo\-doc 1 .
But you could also look
.UR http://example.com/right\-here
here
.UE .


groff -man -Tutf8 -Z -rU1 output (in part):

x X tty: link man:foo-doc(1)
f2
tfoo
N45
h24
tdoc
f1
t(1)
V280
H1248
x X tty: link


groff -man -Thtml -Z output (in part):

x X html:<a href="man:foo\[-]doc(1)">
x font 2 I
f2
tfoo
C\-
h24
tdoc
f1
t(1)
V320
H1248
x X html:</a>


So grotty is producing acceptable output both typographically and in the URI,
whereas grohtml is producing good typography but a URI that will probably lead
to unhappy results.  (Full disclosure: aware of the storied history of \- vs -
in roffs, I implemented grotty link support and modified the treatment of
arguments to the \X escape sequence to accommodate this specific usage in
commit 9d61b3d1, 1 October
<https://git.savannah.gnu.org/cgit/groff.git/commit/?id=9d61b3d142842589b90d7eda0ed3270fbbf6166f>.)

However, grohtml in groff 1.22.4 has this behavior and it's probably been
there a long time.

If this is the only problem "use_charnames_in_special" intends to solve, then
we can get rid of it.  However, I don't know what other purposes it serves. 
I'll investigate.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61401>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/