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

[G. Branden Robinson]

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


[comment #14 comment #14:]
> Exactly, it is not a word gap its a horizontal move.

It seems we are in agreement.  But that is not an argument against this
ticket.
 
> Please can you explain the practical benefit for this change.

Please review bug #63544, which I linked to earlier.  I want to make it easier
for a wider variety of tools to parse GNU _troff_ output, namely including
shell scripts, which (under POSIX shell, at rate) have fairly clumsy
character-based lexical processing capabilities. 

> Perhaps on the list given that it is a change the current api between groff
and the output drivers.

We can discuss it on the list but I strongly object to your characterization
of this as a proposed API change.  It is not.  It honors the letter and spirit
of CSTR #54, and groff's other output drivers are not tripped up by the
change, which suggests that it this _troff_ output is well within James
Clark's expectations.

Here is an example of your output from comment #12 after this change.


$ echo "A Berty" | groff -Tpdf -fU-T -Z
x T pdf
x res 72000 1 1
x init
p1
x font 5 U-TR
f5
s10000
V12000
H72000
md
DFd
tA
w
h2500
tBer
h230
tty
n12000 0
x trailer
V792000
x stop


Since Perl can easily do multi-line matching (though you certainly don't
_have_ to use it), I am not understanding what about the above you find
objectionable. 


    _______________________________________________________

Reply to this item at:

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

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