Arrow head filling patch, and "port.trm"

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

Hi,

  In the process of writing a new terminal type, I noticed that
curr_arrow_headfilled means
  0 no filling, just two lines for an open arrow head
  1 no filling, draw closed arrow head
  2 filled, draw closed arrow head

But the "test" command, which draws 6 arrows, draws the one that points down
using curr_arrow_headfilled set to 3.

This is (accidentally?) processed by do_arrow as a value of 1 would be, since
do_arrow only tests it against !=0 and ==2.

Since this is the only use of a value of of 3, I think the value of 3 in test.c
should be changed to 1.  I posted this one character patch on sourceforge:

--- src/term.c  2006-03-18 19:03:16.000000000 +0000
+++ src/term-new.c      2006-03-31 20:57:34.000000000 +0100
@@ -1963,7 +1963,7 @@
     (*t->arrow) (x, y, x - xl, y, END_HEAD);
     curr_arrow_headfilled = 2;
     (*t->arrow) (x, y, x, y + yl, END_HEAD);
-    curr_arrow_headfilled = 3;
+    curr_arrow_headfilled = 1;
     (*t->arrow) (x, y, x, y - yl, END_HEAD);
     curr_arrow_headfilled = i;
     xl = t->h_tic * 5;

Pre-Announcing "port.trm" :

The ability to write the commands as ascii text to a file descriptor port is why
it is called "port.trm".  The idea to for the parent process to read the
commands and render/process them.

I wanted to run gnuplot as a subprocess and render the output in my main
program.  The easiest way to collect the rendering commands was much like the
debug.trm device.  So the new "port.trm" device uses fprintf to send a legible
ascii description of the rendering commands to either the output file or to an
integer file descriptor passed as a terminal option.

> gnuplot> set term port fd 5 500 500
> Terminal type set to 'port'
> Options are 'fd 5 size 500 500'

Most of the semantics of the options are decoded by "port.trm" into ascii words:

> Arrow 142 170 232 80 (ArrowStyle 18 15 90 AHF_Open DrawLineAndHead AHS_NoHead)

It was in defining all the cases for AHF_Open that I noticed the warning about
the value 3 passed by test.  As a further example, the end of the output of the
test command is then:

> FillBox (FS_Pattern 9) 412 0 12 62
> Move 412 0
> Vector 412 62
> Vector 424 62
> Vector 424 0
> Vector 412 0
> Put_Text 418 68 (LenString 2 (2039))
> LineType 2
> Filled_Polygon (FS_Solid 100) 7 [(400,415),(387,436),(362,436),(350,415),(362,393),(387,393),(400,415)]
> LineType -2
> Justify JCenter
> Put_Text 375 446 (LenString 23 (28636f6c6f72292066696c6c656420706f6c79676f6e3a))
> LineType -2
> Text
> Reset

Where the strings are encoded as hex, preceded by an explicit length.  The
actual rendering of markers and arrows is done with do_point and do_arrow at the
moment.  Their usage will be made optional.  For now, port.trm does not support
enhanced text.

At the other end of the pipe, I have a simple Haskell program that parses the
ascii commands and uses gtk2hs and cairo to render to a window.  This now
handles everything produced by the test command.  The only tricky bit in
rendering it was to rotate the text around the vertical center instead of the
baseline.

But any other program could use the output of "port.trm" in this way.  They just
have to parse the output text.

When it is a bit more polished, I will post a copy of "port.trm" to sourceforge.

-- 
Chris Kuklewicz