bugGNU roff - Bugs: bug #61401, [grohtml] doesn't remap \- in...

 
 

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

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sat 30 Oct 2021 01:57:35 AM UTC
   
 
Category:  Driver grohtml Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 30 Oct 2021 11:42:39 PM UTC, comment #2: 


commit eb695ab2b5e2bae54afa102355c493bda6e29d3e
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat Oct 30 15:45:29 2021 +1100

    [troff]: Fix Savannah #61401.

    [troff]: Handle special character escape sequences that map to basic
    Latin glyphs in device control escape sequences consistently among
    output devices.

    * src/roff/troff/input.cpp (encode_char): Rearrange conditionals.  This
      is the logic that puts the "whatever" within a \X'whatever' escape
      sequence into GNU troff's intermediate output.  Handle stretchable and
      unstretchable space escape sequences ("\ " and \~") first.  Then, if
      the token is a special character escape sequence, retrieve its
      "contents" (glyph name).  Move the basic Latin mapping for the seven
      glyph names '-', 'aq', 'dq', 'ga', 'ha', 'rs', and 'ti' here, before
      checking whether the device description issued the
      'use_charnames_in_special' directive.  This way, the 'html' and
      'xhtml' output devices can straightforwardly embed these basic Latin
      characters in device control escapes (notably, "html:", for which the
      present convention is to follow the this tag immediately with a
      literal HTML URI, complete with `<a href>` element syntax).  If the
      special character is none of these and we should
      'use_charnames_in_special', proceed as groff 1.22.4 and earlier did.
      This is a behavior change, as was my addition of this translation
      mechanism in the first place, so...

    * doc/groff.texi (Postprocessor Access): Document it.

    * src/roff/groff/tests/device_control_escapes_express_basic_latin.sh:
      Test it.
    * src/roff/groff/groff.am (groff_TESTS): Run test.

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


G. Branden Robinson <gbranden>
Group administrator
Sat 30 Oct 2021 05:44:55 AM UTC, comment #1: 

Everything I need to change to scratch my itch is in src/roff/troff/input.cpp:encode_char() (which has a narrower scope than its name suggests).

There are only four tests of 'use_charnames_in_special'.  Three of them are in encode_char().  The other is in the file_iterator class constructor.

I think I have enough information to proceed.

G. Branden Robinson <gbranden>
Group administrator
Sat 30 Oct 2021 01:57:35 AM UTC, original submission:  

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

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.

G. Branden Robinson <gbranden>
Group administrator

 

(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 (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
    2021-10-30 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2021-10-30 gbranden StatusNeed Info In Progress

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code