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/
