Re: Arrow head filling patch, and "port.trm"

[Chris K <gnu...@li...>]

I sit corrected.

Hans-Bernhard Br=F6ker wrote:
> Chris K wrote:
>> Hans-Bernhard Br=F6ker wrote:
>=20
>>> Looks like you're re-inventing the 'xlib' terminal.  And/or tkcanvas.
>=20
>> I mildly disagree.  I re-invented debug.trm.
>=20
> No.  You may have started out from debug.trm, by you ended up with
> something that's really a good deal closer to xlib.trm than to
> debug.trm, in functionality.  Debug.trm is for humans, not machines, to
> read.  Xlib.trm is basically not more than a stream serialization of th=
e
> gnuplot terminal API, to be read by a program like gnuplot_x11.

Okay...now I actually read and tested it.  And learned more about the sem=
antics,
which was helpful.

> The x11 commands *are*, for almost all intents and purposes, the
> original commands.  PM.trm and WIN.trm are very similar to this, in
> approach, although their implementation is somewhat different.
>=20

For the most part, that is true.

>> This is highly specialized to x11.
>=20
> Not really.  All the X11-specific code is outside x11.trm.  Up until
> about version 3.7 or so, this even extended to the point that the main
> gnuplot programs wasn't even linked to the X11 libraries.
>=20
>> In the end, gnuplot gains to ability to drive a rendering program via
>> the output
>> file, which I will redirect to a pipe (/dev/fd/5). =20
>=20
> It already has that ability, in the shape of xlib.trm.  Only the syntax
> is different from your work, but not the semantics.
>=20

Observations from reading the x11 syntax and useful things I have learned=
:

0) It is a mixed text and binary protocol.  IMHO, this is ugly enough tha=
t I
won't make the same choice.  All or nothing, probably via a "set term por=
t
binary|text" option.

1) The strings sent by gnuplot to put_text do not have '\0' or '\n' chara=
cters
in them.  This is a useful property to be certain about.  This is also tr=
ue for
enhanced text.  Now I don't have to print the text characters as hex byte=
s to
avoid strange escaping rules.

2) The coordinates are printf'd with "%4d" which limits their size.  This=
 limit
to a size of 10000 should be added to the help text.  I want to oversampl=
e, so I
 exceed this limit, and thus I have no chance of using xlib's output.

3) The binary encoding uses something I had not seen before. It shifts th=
e byte
values to minimize the number of '\0' and '\n' characters, and then escap=
e them
by sending an escape code (0x05) (and escape the escape).  These strange
escaping rules have different magic numbers depending on the command, and=
 the
escaping changes the number of bytes written.  Going to a 100% binary pro=
tocol
would simplify this.

4) The endian issue is handled at runtime in a smooth way, by sending a k=
nown
value at the start (like in UTF-16/32 encodings).  I like it.  Alternativ=
ely I
could force network byte order.

5) Drawing points is punted to the downstream renderer.  Drawing arrows i=
s
punted to gnuplot's do_arrow.  I intend to make these two binary choices =
options
to "set term port".

6) x11 does what my haskell code does:  It creates a pipe then calls fork=
 and
exec and fdopen.  The only difference with the haskell code is which proc=
ess
creates which.  The x11 driver also can make a second pipe for getting
information back, which I have not done yet.

7) The magic number of the protocol are in "src/gplt_x11.h" instead of x1=
1.trm

Looking at pm.trm : It use a pipe of some kind, and include "os2/pm_msgs.=
h" for
the magic numbers of the binary protocol, a file that is not part of gnup=
lot.

Looking at win.trm : Uses "src/win/wgnuplib.h" for the magic constants.

--=20
Chris