Follow-up Comment #27, bug #64360 (project groff):
First I'd like to try to reduce the scope of this discussion, since it seems
to have grown in multiple directions.
Am I correct in the assumption that the grout files for any given input would
not be identical when produced by different roff implementations? I assume
this is true, else the output drivers from different implementations would be
interchangeable. I don't believe they are.
This means, whilst they may all be based on the information in cstr#54, each
roff has developed its own private API between the formatter and output
drivers. For this reason the decision on whether this is a change to the groff
version of the API, has to be confined to what is contained in the groff
documentation.
Empirical observation shows that groff uses a simple rule of one operation per
line and using a single space to avoid a "clashing between the command code
and the arguments without the space.", even though Kernighan states that it is
permitted to use newlines as well as a space and tab for this purpose, none of
our drivers support this.
The w command is not an operation, it is just a marker for a paddable word
space so following with a newline is against our own documentation:-
in 'gtroff''s intermediate output, every command with
at least one argument is followed by a line break, thus providing
excellent readability.
The w command has no arguments so under this rule it should not have a
following new line.
As regards having a space after the w command, our documentation says:-
The 'gtroff' output parser, however, is smart about whitespace by making it
maximally optional.
Which I take to mean it only uses a space to avoid the "clashes" mentioned
above, and it further says:-
Commands and arguments with a known, fixed length need
not be separated by syntactical space.
The w command is fixed length, so to satisfy "maximally optional" no space is
used.
I never said that white space cannot follow a w command, but if we change to
include white space after it then that goes against how the groff version of
the API has been documented for many years.
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). If groff 1.23++ is going to use w
followed by a new line, none of the proposed patches is optimal. A loop is no
longer required, since no further commands will be on that line. There is no
point in producing code to cater for situations which will not arise. Gropdf
is written to parse grout output from groff, if that output is altered so that
it no longer complies with our own documentation and gropdf fails to handle it
then it is not a bug, but a change in the API and should involve a change
request and at least a wider discussion than just us three.
Apparently, the reason for wanting to make this change is to "generate "grout"
that is more easily lexically analyzed". Citing posix shell's poor lexical
processing capabilities, I don't see what difference wh2500 and w\nh2500
makes. If that's what you want, would a simple filter like this help:-
[derij@pip busgrap]$ perl -pe 's/(.)(.*)/$1\n$2/ if m/^w/; s/^(.)(\S.*)/$1
$2/mg' zfile
x T ps
x res 72000 1 1
x init
p 1
x font 5 TR
f 5
s 10000
V 12000
H 72000
m d
D Fd
t Deri
w
h 2500
D l 100000 0
n 12000 0
x trailer
V 792000
x stop
In fact I'd be very happy to write a proper grout tool with multiple output
options (pretty print, markup, XML). Markup could look like:-
x T ps # for grops
x res 72000 1 1
x init
p1 # Page 1
x font 5 TR
f5 # Times-Roman
s10000 # ps 10
V12000 # V 1/6th in
H72000 # H 1in
md # Default text colour: Black
DFd # Default fill colour: Black
tDeri
wh2500 # Word Space: 2.5p
Dl 100000 0 # Line from x,y to x1,y1
n12000 0 # New Line
x trailer
V792000
x stop
Using some of the code from gropdf which keeps track of current position, XML
output could tag the x,y position of every element.
So it is unnecessary to change the format of grout to achieve what you say you
want.
The danger in changing the current grout format is we do not know what tools
have been written which parse our current grout format, didn't someone write a
parser which output html/javascript, how do we know our changes won't affect
them. Given that there are non-intrusive methods to achieve the result you
want, I hope your hankerings can be satisfactorily assuaged.
AOB
Many people have praised Branden for his contributions to the documentation,
as I do, it just felt wrong to see open criticism of a fellow contributers use
of english. I am more than happy for Branden to make our documentation more
"pellucid", but I think it is nicer to do it without denigrating previous
efforts which were made with the best intentions.
Dave, I don't use dasher for coding, just a keyboard, which is slower for
input, but better for navigating around the document, cut and paste,
controlling indentation and such like. For a maths exam at school they gave me
an amanuensis, a very nice retired lady who spent the whole time doing a
birdseye view of what her ideal home would look like. Gradually adding more
and more detail with a multitude of coloured pencils (each had to be sharpened
before use) right down to drawing individual roses in a regular pattern on the
living room blue carpet - I was fascinated! Unfortunately she did not know how
to draw an integral sign, so that took some explaining! This was before
personal computers, oh for groff and eqn then.
The latest incarnation of gropdf (in the deri-gropdf-ng git branch, give it a
go :-)) is now 80 lines short of 5000 lines.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64360>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
