[bug #63099] nroff/troff difference when measuring arguments in compatibility mode

[G. Branden Robinson]

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

                 Summary: nroff/troff difference when measuring arguments in
compatibility mode
                 Project: GNU troff
               Submitter: gbranden
               Submitted: Sat 24 Sep 2022 04:59:28 PM UTC
                Category: Core
                Severity: 2 - Minor
              Item Group: Warning/Suspicious behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 24 Sep 2022 04:59:28 PM UTC By: G. Branden Robinson <gbranden>
This surprised me.

Input:


.de Mw
.  nr wd \w'\\$1'
.  tm "\\$1" is \\n(wd units wide.
..
.Mw Wet'suwet'en
.Mw Wet'+200i
.cp 1 \" turn on compatibility mode
.Mw Wet'suwet'en
.Mw Wet'
.Mw Wet'+200i


With compatibility mode on, we would expect the first embedded ' character to
terminate the argument given to the \w escape sequence.

And for PostScript output, it does.


"Wet'suwet'en" is 54740 units wide.
"Wet'+200i" is 42610 units wide.
"Wet'suwet'en" is 15860 units wide.
"Wet'" is 15860 units wide.
"Wet'+200i" is 14415860 units wide.


But watch what happens when we try a terminal device.


"Wet'suwet'en" is 288 units wide.
"Wet'+200i" is 216 units wide.
"Wet'suwet'en" is 240 units wide.
"Wet'" is 72 units wide.
"Wet'+200i" is 48072 units wide.


Note the third line.  \w kept reading until it hit the _second_ embedded
apostrophe.

This is pretty bizarre but I can't bring myself to set it to a higher severity
than "minor" because it seems to me like a pretty obscure corner case--using
compatibility mode and inside knowledge of the delimiter to be used inside a
macro you're calling.

Still, I'm curious to research this, maybe for groff 1.24.







    _______________________________________________________

Reply to this item at:

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

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