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

[G. Branden Robinson]

Follow-up Comment #30, bug #64360 (project groff):

How about something briefer?

[comment #29 comment #29:]
> > I believe the change Branden has on his private branch is to output a new
line after a w command, but this bug concerns white space after the w.
Contrary to cstr#54, which classes space/tab/newline as the same, groff does
not allow newline to be used as the white space between a command and its
arguments (this difference is not documented).
> 
> That's a good interesting point and one I want to explore with further
testing.  I see no reason _groff_ output drivers _shouldn't_ accept a newline
thus, given the clarity of CSTR #54's wording on the subject.

Findings:

Given the attached input, which exclusively uses newlines for separation:

1. _grops_ rejects the input.


$ grops /tmp/branden/ps-grout3 > /tmp/branden/three.ps
grops:/tmp/branden/ps-grout3:1: error: missing argument
grops:/tmp/branden/ps-grout3:1: fatal error: the first command must be 'x T'


2. Heirloom dumps core.


$ ./bin/dpost /tmp/branden/ps-grout3 >| /tmp/branden/hthree.ps
Segmentation fault (core dumped)


3. DWB 3.3 troff gets upset with GNU extensions.  Its input line counter also
gets completely out of whack.


$ DWBHOME=. ./bin/dpost /tmp/branden/ps-grout3 >| /tmp/branden/hthree.ps
./bin/dpost: unknown input character 155 m (line 11)
[drop the 'm' command]
$ DWBHOME=. ./bin/dpost /tmp/branden/ps-grout3 >| /tmp/branden/hthree.ps
./bin/dpost: unknown drawing function 
 (line 11)
[drop the 'D f' command]
$ DWBHOME=. ./bin/dpost /tmp/branden/ps-grout3 >| /tmp/branden/hthree.ps
./bin/dpost: unknown input character 141 a (line 11)


I was able to determine that DWB 3.3 doesn't like newlines after 'c' commands
or 'x' commands, but even after "fixing" those it kept throwing errors.  I
didn't keep chasing it.

(But I am assured that if my input has a problem, it's on line 11.)

It seems *everyone* is sinful according to the gospel of CSTR #54...

I suggest splitting this issue off into a new ticket if anyone wants it fixed.


    _______________________________________________________

Reply to this item at:

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

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