[bug #64360] [gropdf] does not correctly handle white space after 'w' command

[G. Branden Robinson]

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

                 Summary: [gropdf] does not correctly handle white space after
'w' command
                   Group: GNU roff
               Submitter: gbranden
               Submitted: Tue 27 Jun 2023 03:17:09 PM UTC
                Category: Driver gropdf
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Tue 27 Jun 2023 03:17:09 PM UTC By: G. Branden Robinson <gbranden>
Input:


A B


This produces the following output from GNU troff.


x T pdf
x res 72000 1 1
x init
p1
x font 5 TR
f5
s10000
V12000
H72000
md
DFd
tA
wh2500
tB
n12000 0
x trailer
V792000
x stop


If we modify this output to put a space after the 'w' command, _gropdf_
incorrectly omits the space between "A" and "B".

If we modify this output to put a newline after the 'w' command, _gropdf_'s
parser gets into a bad state, but correct output is produced.


substr outside of string at ./build/gropdf line 376, <> line 13.
Use of uninitialized value $lin in substitution (s///) at ./build/gropdf line
380, <> line 13.


_gropdf_ handles a comment (which must end with a newline) after 'w'
correctly.

CSTR #54 (1992) permits the variations above. "Blanks, tabs, and newlines may
occur in the as separators in the input, and are mandatory to separate
constructions that would otherwise be confused."

_grops_(1) appears to behave correctly in both scenarios, and since the
parsing code is in _libdriver_, probably all of _groff_'s other output drivers
do.

I didn't test tabs, for the not very good reason that I am dubious about the
worth of tab characters ever occurring in GNU _troff_ output.  Also, since
_gropdf_ appears to be using '\s' for matching in its logic, the way Perl
regexes define '\s' should handle the tab scenario the same as the space.








    _______________________________________________________

Reply to this item at:

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

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