gnuplot-beta — Developers and beta testers of new gnuplot code

Re: update for www.gnuplot.info

[Lars H. <lhe...@us...>]

Petr Mikulik writes:
> According to SourceForge Patch:
> 
> [ 790847 ] Updated link to Gnuplot.py for gnuplot homepage
> 
> The gnuplot homepage contains a link to Gnuplot.py, the
> Python interface to gnuplot. But the link is obsolete.
> Please change it to
> 
> http://gnuplot-py.sourceforge.net/
> 
> 
> Can someone fix it on gnuplot.info?
 
 gnuplot.info should pick it up with the next resync.

update for www.gnuplot.info

[Petr M. <mi...@ph...>]

According to SourceForge Patch:

[ 790847 ] Updated link to Gnuplot.py for gnuplot homepage

The gnuplot homepage contains a link to Gnuplot.py, the
Python interface to gnuplot. But the link is obsolete.
Please change it to

http://gnuplot-py.sourceforge.net/


Can someone fix it on gnuplot.info?

---
Petr Mikulik

Re: unlimited windows patch

[Ethan M. <merritt@u.washington.edu>]

On Monday 24 November 2003 07:53, Petr Mikulik wrote:
> What I would really love now is that "space-bar" hotkey working in x11
> terminal in gnuplot running under KDE's Konsole. It works in xterm,
> gnome terminal, but not in Konsole. I've tried to ask at several places=
,
> but nobody answered.
>
> Does somebody an idea what to do now? Whom/where to ask for help?

I've no idea, but I don't think this has anything in particular to do wit=
h gnuplot.
Konsole is broken in so many ways that I gave up on it long ago.
There are so many good alternatives (xterm, rxvt, eterm,...) that it does=
 not
seem worth worrying about.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: bug in variable.c: fontpath_handler(ACTION_GET)

[Petr M. <mi...@ph...>]

> > There seems to be a bug in file
> > 	variable.c
> > which sometimes causes 'test palette' to segfault. It shows up in some
> > combinations of save_set(), load_file(), and do_string("reset;");
> >
> > "valgrind" helped to discover the problematic place. It is in routine
> > fontpath_handler(action, path) in case ACTION_GET:
>
> It's hard to discuss the fix without an explanation what the actual bug
> was.  How did it segfault?

Try this:

$ valgrind gnuplot
....
Terminal type set to 'x11'
gnuplot> test pal
==30824==
==30824== Conditional jump or move depends on uninitialised value(s)
==30824==    at 0x40162EB7: malloc (in /usr/lib/valgrind/valgrind.so)
==30824==    by 0x804B0F4: gp_alloc (alloc.c:280)
==30824==    by 0x8053A80: test_palette_subcommand (command.c:1363)
==30824==    by 0x805216B: command (command.c:507)
gnuplot> test pal
==30824==
==30824== Invalid read of size 1
==30824==    at 0x4016371B: strlen (in /usr/lib/valgrind/valgrind.so)
==30824==    by 0x80E88BC: fontpath_handler (variable.c:519)
==30824==    by 0x809225B: save_set_all (save.c:826)
==30824==    by 0x8090807: save_set (save.c:100)
==30824==    Address 0x0 is not stack'd, malloc'd or free'd
Segmentation fault


(The 1st report is not an issue for the 2nd.)

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

[Hans-Bernhard B. <br...@ph...>]

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> There seems to be a bug in file
> 	variable.c
> which sometimes causes 'test palette' to segfault. It shows up in some
> combinations of save_set(), load_file(), and do_string("reset;");
> 
> "valgrind" helped to discover the problematic place. It is in routine
> fontpath_handler(action, path) in case ACTION_GET:

It's hard to discuss the fix without an explanation what the actual bug
was.  How did it segfault?

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: unlimited windows patch

[Petr M. <mi...@ph...>]

> > that I'd like people to test and consider for integration into Gnuplot.  One
> > is a moderate length patch for unlimited X11 windows.  The other is the
> > longer patch for image and binary data file support.  I will briefly discuss
> > the two in separate emails...
> >
> > Patch 774822 Unlimited plot windows for X11 terminals.
> >
> > linked_list_103003.diff
>
> I think the patch has been carefully tested by several people and it works
> fine. What about if I move it to cvs?

It is there. Thanks for the patch.

===

What I would really love now is that "space-bar" hotkey working in x11
terminal in gnuplot running under KDE's Konsole. It works in xterm, gnome
terminal, but not in Konsole. I've tried to ask at several places, but
nobody answered.

Does somebody an idea what to do now? Whom/where to ask for help?

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

[Harald H. <h.h...@tu...>]

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> There seems to be a bug in file
> =09variable.c
> which sometimes causes 'test palette' to segfault. It shows up in some
> combinations of save_set(), load_file(), and do_string("reset;");
>
> "valgrind" helped to discover the problematic place. It is in routine
> fontpath_handler(action, path) in case ACTION_GET:
>
> Below is an ad-hoc fix -- and actually two possibilities of the fix. Does
> someone (Harald?) know what that code is doing and propose a correct fix?

It's ages ago that I have programmed the fontpath handling. But I will
have a look at it at home. Please give me two days to find it out again.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Institut f=FCr Werkstoffe                  D-38106 Braunschweig
Technische Universit=E4t Braunschweig      Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

bug in variable.c: fontpath_handler(ACTION_GET)

[Petr M. <mi...@ph...>]

There seems to be a bug in file
	variable.c
which sometimes causes 'test palette' to segfault. It shows up in some
combinations of save_set(), load_file(), and do_string("reset;");

"valgrind" helped to discover the problematic place. It is in routine
fontpath_handler(action, path) in case ACTION_GET:

Below is an ad-hoc fix -- and actually two possibilities of the fix. Does
someone (Harald?) know what that code is doing and propose a correct fix?


diff -uwr src/variable.c src-TestPal/variable.c
--- src/variable.c	2002-10-11 18:26:00.000000000 +0200
+++ src-TestPal/variable.c	2003-11-23 17:46:33.000000000 +0100
@@ -302,6 +302,7 @@
 	init_fontpath();
     }

+
     switch (action) {
     case ACTION_CLEAR:
 	/* Clear fontpath, fall through to init */
@@ -516,6 +517,15 @@
 	    else
 		return NULL;
 	} else {
+//@@@@@@@@@@@@@@@@@@@ bug in variable.c:
+//@@@@@@@@@@@@@@@@@@@ fontpath_handler(action, path) for ACTION_GET:
+//@@@@@@@@@@@@@@@@@@@ PETR: WHAT IS CORRECT HERE ??? WHICH FIX?
+#if 1
+if (p == NULL) { beenhere = 0; return NULL; }
+#else
+if (p == NULL) { return NULL; }
+#endif
+//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ END OF A BUG FIX
 	    p += strlen(p);
 	    /* skip over '\0' */
 	    p++;

Re: test palette rgb

[Petr M. <mi...@ph...>]

> > A snapshot is here:
> >   http://www.sci.muni.cz/~mikulik/gnuplot/gp_rgb.png
>
> I see.
> I like that!

So it is in cvs.

Associated changes:

- 'test' is synonym for 'test terminal'

- Undocumented command 'testtime' changed to undocumented command
'test time'.

BTW, is there any particular reason this to be undocumented, now, when it is
a suboption of 'test'? Cannot it be changed to become useful for users of
"time" plots?

---
Petr Mikulik

Re: arrowheads too long in PostScript terminal

[Daniel J S. <dan...@ie...>]

Alan, Ethan,

I've drawn up a diagram illustrating the tip of an arrow
and how to compensate for the line ending so that the
tip lands right at the desired end point.  It is in PDF format
at:

http://acer-access.com/~ds...@ac.../

under "gnuplot stuff".

The formula is actually quite simple given the angle of
the tip "wings" as specified in Gnuplot.  Basically a small
vector opposite the direction of the vector from start (S) to
end (E) is added to the end point (E).

Here is a small chunk of code that implements the formula
intended for the "place_arrows" routine in graphics.c.  But
THIS DOESN'T WORK currently (read below) so just
illustrates the simplicity of the formula.

    apply_head_properties(&(this_arrow->arrow_properties));
    /* A correction factor for the line so that the arrow head does
     * not extend past the ending point of the line.
     *
     * THIS IS CURRENTLY JUST A DEMONSTRATION AND DOESN'T ACCOUNT
     * FOR ALL THE SPECIAL CONDITIONS LIKE headlength < 0, alpha = 0,
     * ETC.
     */
    if (this_arrow->arrow_properties.head_length > DBL_EPSILON) {
        double dx = (double) sx - (double) ex;
        double dy = (double) sy - (double) ey;
        double len_arrow = sqrt(dx * dx + dy * dy);
        double alpha = this_arrow->arrow_properties.head_angle * DEG2RAD;
        double w = this_arrow->arrow_properties.lp_properties.l_width;
        double factor = w/(2*len_arrow*sin(alpha));
        ex += dx*factor;
        ey += dy*factor;
    }
    (*t->arrow) (sx, sy, ex, ey, this_arrow->arrow_properties.head);

OK.  This doesn't work because THE LINE WIDTH IS NOT KNOWN
IN TERMS OF PLOT UNITS.  That is, in the formula above, "w" should
be the line width in terms of plot units not in terms of "unity" units.  You
see, the line width properties are sent all the way down to the driver level
and I think it is there that the value of "lp_properties.l_width" takes on a
meaning.

So there are a couple significant problems here in compensating for the
tip of the arrow.

1)  Where should the compensation for the arrow tip be done?  The
options are inside the Gnuplot "place_arrow" routine, inside the
default terminal "do_arrow" function, or inside each individual driver's
"arrow" function.  There are pluses and minuses for all.

2)  Somewhere the width of a line must be known in terms of plot
units in order to compensate for the arrow tip.  I don't see where this
information can be gotten easily and this could be some major
driver level coding to send back such information.  (Ethan, is this
similar to the problems you've come across with getting font height
information back from the driver?)

Dan



Alan G Isaac wrote:

>>On Monday 20 October 2003 23:14, Alan G Isaac wrote:
>>    
>>
>>>Basic user interface issue:
>>>set arrow from ptA to ptB
>>>will be expected to do precisely that:
>>>start at ptA and end at ptB.
>>>      
>>>
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>Gnuplot does that now.  What we are disagreeing about is the
>>meaning of the word "precisely".
>>    
>>
>
>Actually I think we are disagreeing on the more basic words
>'start' and 'end'.  I have not been able to understand your
>apparent suggestion (?) that the user will expect ink past
>ptB (in the direction of the arrow).
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>You may not like the behavior, but that doesn't mean it
>>is ambiguous.
>>    
>>
>
>I think you are giving a programmer's perspective rather 
>than a user's perspective on ambiguity here.  Of course,
>the code says what it says.  But a user has no simple
>way to tell where an arrow will end. (I.e., where the
>ink will end.)
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>think of line segments in gnuplot as a
>>connect-the-dots process:  place a dot at the "from"
>>position, place another at the "to" position, then connect
>>them.
>>    
>>
>
>I accept that if I draw several independent (i.e., unjoined)
>line segments end to end that round caps will produce a
>better looking line.  But this is not how people use arrows.
>Or rather, I don't know anyone using arrows this way.
>And those who do have a round caps option available to them.
>
>  
>
>>I personally think that rounded ends are best.
>>But it should be left up to the user, as it is now.
>>    
>>
>
>No, it isn't.  Not for arrows with heads.  Selecting butt
>caps does not cause arrowhead ink to terminate at the
>specified end point.
>
>
>  
>
>>But they don't.   They extend exactly to the specified
>>endpoint *** to the resolution of the pen used ***.
>>    
>>
>
>  
>
>>>What is more, with
>>>this behavior it is essentially impossible for me to make an
>>>arrow terminate precisely where I wish it to.
>>>      
>>>
>
>  
>
>>I don't see why.  Can't you just specifiy a very thin
>>pen width and a filled arrowhead?  Stroke the tail of
>>the arrow separately if you want that part thicker.
>>    
>>
>
>Stroke the tail to where, exactly?  (That is the 
>user interface issue!)
>
>A picture is worth a thousand words.  How can the sript
>below be considered to produce desirable output for these
>script commands?  I still say the key issue is: what will
>users expect, and what makes it easiest for them to achieve
>precisely what they desire in a predictable fashion?  When
>the user wants an arrow from ptA to ptB, that really ends at
>ptB (i.e., no ink past ptB), s/he should not have to make
>length adjustments everytime s/he changes the linewidth or
>arrowhead angle.  Yet that is the current situation.  I
>cannot see that this behavior (in the sample script) can
>meet the goal of being predictable for the user.  And I add
>to that a personal query: thinking back over your own use of
>arrows in gnuplot, can you really claim that your *intent*
>when you first think of drawing an arrow from ptA to ptB
>is for the ink to extend past ptB?
>
>Alan Isaac
>
>##############################################################
>set term post eps color solid butt
>set output 'c:\temp3.eps'
>set xrange [0:4]
>set yrange [0:5]
>set style arrow 1 front head size 0.2,15 nofilled lt -1
>set style arrow 2 front nohead lt -1
>set style arrow 3 front nohead lw 5 lt -1
>set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1
>set arrow from  1,1 to 3,1 as 1
>set arrow from  1,2 to 3,2 as 2
>set arrow from  1,3 to 3,3 as 3
>set arrow from  1,4 to 3,4 as 4
>plot '-' with points ps 1 pt 7 lt 1
>3 1
>3 2
>3 3
>e
>##############################################################
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN developer relations
>Here's your chance to show off your extensive product knowledge
>We want to know what you know. Tell us and you have a chance to win $100
>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: Universal enhanced text mode!

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 19 November 2003 00:55, you wrote:
> Well, this shift can also be seen on the "dumb enha" terminal -- but it=
s
> character size should not be scalable so that {/*4 } should alway be se=
t
> to 1, I think? The same for other terminals with non-scalable fonts.

But is this a bug?  The program is doing what you tell it to do - scale
the font size by some large factor.  The optimal choice of font and scali=
ng
is always going to depend on the specific output device, so I think the
user is ultimately responsible for requesting reasonable values.

This behavior is also present in the original PostScript code.
The placement of the sub- and superscripts is calculated separately
by the layout code, and if you tell it there is a large font it will plac=
e them
far above or below the baseline.   gnuplot does not really know if the
font size information is correct or not, it just assumes that if you sele=
ct
a font size you know what you are doing.

And even for PostScript output this assumption can go wrong.
Gnuplot calculates text  placement based on the font information
present at the time you create the plot.  But if you print the output fil=
e on
a printer that  does not have that font, the printer will substitute some
other font and the sub/superscript placement may well be incorrect.

This is exactly parallel to the X11 case.  You tell gnuplot that
such-and-such a font is to be used, and what size it is=20
supposed to be.  Gnuplot positions text accordingly, then
sends the output to a separate program (gnuplot_x11)=20
which in turn sends it to an X-server.  And that X-server
may not have that font, or may not be able to provide the
size requested.  But this failure is too late, and in the wrong
program, for gnuplot to do anything about it.

OK, yes, I agree that the dumb terminal driver is never going
to be able to scale fonts.  So maybe it is a special case.
But I was not really worried about producing optimal output
on the dumb terminal. Do you think this is important?

And if I change it so that the scale factor is ignored in some
cases,  then you will lose the ability to tweak the scale factor if you
*do* in fact want to adjust the sub- and super- scripts placement.
For instance if you have multiple levels of sub/superscripts
=09label =3D "{x^{k_1}}"
You need to request a larger font scaling in the dumb terminal
in order to spread the k-sub-1 over two lines.

There are more complex options, I suppose.
We could create a new style option
=09set font [no[scaleable]] [charset <val>] [... others?]
But I think this can all come afterwards, if people find that
the current mechanism is inadequate in practice.


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: test palette rgb -- Re: show palette palette <n> savergb

[Petr M. <mi...@ph...>]

> > I propose
> > 	test palette {{rgb | grb | bgr | rbg | ...}}
> >
> > to get the user chance to distinguish which R,G,B profiles overlap in
> > e.g. gray palette.
>
> I'm afraid I don't understand what you are saying here.
> Probably a picture is worth a thousand words of explaination.
> What is the difference between
> 	test palette rgb
> and
> 	test palette grb
> in the resulting output?


Being the rgb profiles in 'tmpfile', the option rgb | bgr | ... would choose
this order:

plot 'tmpfile' \
  u 1:2 title 'red'w l 1, ''u 1:3 tit 'green'w l 2, ''u 1:4 tit 'blue' w l 3

or this one

 using 1:4 'blue', u 1:3 'green', u 1:2 'red'

or ....

In principle, it select which color curve will be on top if (at least) two
overlap like e.g. in 'palette gray' (all 3 r,g,b profiles overlap).

A snapshot is here:
  http://www.sci.muni.cz/~mikulik/gnuplot/gp_rgb.png

---
Petr Mikulik

Re: Success!

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Tuesday 18 November 2003 12:30, you wrote:
>  
>
>>If it seems to be working now, I will leave it as is and upload
>>it to SourceForge.  If anything seems strange, let me know.
>>    
>>
>
>Quick status update:
>
>I started over again on the alpha with the current cvs source
>patched with your  with_image_111603.diff
>It failed.
>I then started introducing changes one by one from my
>working version.  The key lines were ones you had identified
>earlier:
>#if (0)  /* Doesn't work on alpha */
>#define SET_COLOR_CODE_CHAR      '\x005'
>#define FILLED_POLYGON_CODE_CHAR '\x005'
>#define IMAGE_CODE_CHAR          '\x001'
>#else
>#define SET_COLOR_CODE_CHAR      '5'
>#define FILLED_POLYGON_CODE_CHAR '5'
>#define IMAGE_CODE_CHAR          '1'
>#endif
>

Good, good.  I wonder if the DEC cc compiler thinks that '\x001'
means 'x', when it really is supposed to mean 1.

>With this change on top of the 111603 patch, the alpha
>version can communicate with itself just fine.  How I managed
>to screw this up while testing from home, I do not know.
>

This could be a case of the compilation not appropriately
checking dependence.  x11.trm is dependent upon gplt_x11.h
but since x11.trm is compiled through term.c, it may not
recompile when gplt_x11.h is changed.  I'm not positive on
that.

>It's water under the bridge at this point, I suppose.
>
>However, the 32-bit and 64-bit streams are still not
>interchangeable. In fact they are not even the same length.
>

I will have a look at how these differ.

Thanks,

Dan

Re: Success!

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 18 November 2003 12:30, you wrote:
> If it seems to be working now, I will leave it as is and upload
> it to SourceForge.  If anything seems strange, let me know.

Quick status update:

I started over again on the alpha with the current cvs source
patched with your  with_image_111603.diff
It failed.
I then started introducing changes one by one from my
working version.  The key lines were ones you had identified
earlier:
#if (0)  /* Doesn't work on alpha */
#define SET_COLOR_CODE_CHAR      '\x005'
#define FILLED_POLYGON_CODE_CHAR '\x005'
#define IMAGE_CODE_CHAR          '\x001'
#else
#define SET_COLOR_CODE_CHAR      '5'
#define FILLED_POLYGON_CODE_CHAR '5'
#define IMAGE_CODE_CHAR          '1'
#endif

With this change on top of the 111603 patch, the alpha
version can communicate with itself just fine.  How I managed
to screw this up while testing from home, I do not know.
It's water under the bridge at this point, I suppose.

However, the 32-bit and 64-bit streams are still not
interchangeable. In fact they are not even the same length.
I attach two output streams for the impersonations demo.
Each works on the machine it was generated on, but not
on the other machine.  I'd say it's OK to call the code
"working" at this point, since it does work on any given
machine.  But if your goal is data interchange, then some
further investigation and cleanup is still needed.

=09Ethan


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: test palette rgb -- Re: show palette palette <n> savergb

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 18 November 2003 03:44, Petr Mikulik wrote:
>
> I propose
> =09test palette {{rgb | grb | bgr | rbg | ...}}
>
> to get the user chance to distinguish which R,G,B profiles overlap in
> e.g. gray palette.

I'm afraid I don't understand what you are saying here.
Probably a picture is worth a thousand words of explaination.
What is the difference between
=09test palette rgb
and
=09test palette grb
in the resulting output?

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: unlimited windows patch

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 18 November 2003 06:00, Petr Mikulik wrote:
> > Patch 774822 Unlimited plot windows for X11 terminals.
>
> I think the patch has been carefully tested by several people and it
> works fine. What about if I move it to cvs?

OK by me.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: unlimited windows patch

[Petr M. <mi...@ph...>]

> that I'd like people to test and consider for integration into Gnuplot.  One
> is a moderate length patch for unlimited X11 windows.  The other is the
> longer patch for image and binary data file support.  I will briefly discuss
> the two in separate emails...
>
> Patch 774822 Unlimited plot windows for X11 terminals.
>
> linked_list_103003.diff


I think the patch has been carefully tested by several people and it works
fine. What about if I move it to cvs?

---
Petr

test palette rgb -- Re: show palette palette <n> savergb

[Petr M. <mi...@ph...>]

> > Also, would it not be equally (or even more) useful to have a
> >     'test rgbpalette'
> > that displays in the plot window an indexed array of the
> > palette colors?
>
> That would be really nice. It could be done most easily like that:
>   - save rgb table with 256 samples into a temporary file
>   - plot it by a call to "do_string"

I have it working exactly that above-mentioned way. So, what should be the
syntax?

I propose
	test palette {{rgb | grb | bgr | rbg | ...}}

to get the user chance to distinguish which R,G,B profiles overlap in e.g.
gray palette.

---
Petr Mikulik

Re: Universal enhanced text mode!

[Petr M. <mi...@ph...>]

> I have added reference implementations for
>     post   gd   pdf   x11   dumb

I've tried OS/2 PM terminal, and it still works -- it is not touched by the
patch. This terminal, 'set term pm enha' has an independent implementation
of postscript enhanced features in gclient.c:ParseText() for years.

Would there be some profits for this terminal if it uses your new scheme?
Can you make a patch for it? (I can try to test it.)


> The postscript output is character-for-character identical to
> the output the original version.
> Implementations for gd, pdf, and x11 are 99% complete.

I just wonder: would not it be possible to need less new API functions? For
example, to pass some structure of parameters, and call the same API several
time for slightly different purposes. I remember the discussion here few
years ago, that there are too many API there ... and some could be grouped
together, and those for text properties are good candidates.


BTW, there is a small bug:

set term x11 enha
set title '{/*10 x_2}'
  ... it shifts subscript too much down

Petr

Re: Purpose of xlib terminal ?

[Ethan M. <merritt@u.washington.edu>]

> On Mon, 17 Nov 2003, Hans-Bernhard Broeker wrote:
> > Xlib output is supposed to be to the x11 driver what the
> > EMF driver would be for the Windows driver.  It's essentially a
> > metafile, i.e. a stored record of drawing commands. In theory, this
> > lets you run gnuplot itself and gnuplot_x11 on different machines.
> >
> > =09rsh somebox gnuplot scriptfile | gnuplot_x11

On Monday 17 November 2003 05:13, Jonathan Thornburg wrote:
> I have used a slight variant a lot:
>
>     set term gnuplot_x11
>     set output 'movie.gnuplot-x11'
> then copy to another machine and play the movie there via
>     gnuplot_x11 <movie.gnuplot-x11


OK. Then I propose to replace the existing xlib.trm code with a
minimal xlib.trm that has its own term->init to set up the output
file, but uses the normal x11.trm routines for everything else.
That way it stays current with x11 when changes are made,
yet takes up virtually no space on its own.
Already tested.  It works as expected.


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: Purpose of xlib terminal ?

[Jonathan T. <jt...@ae...>]

On Mon, 17 Nov 2003, Hans-Bernhard Broeker wrote:
> Not really.  Xlib output is supposed to be to the x11 driver what the EMF
> driver would be for the Windows driver.  It's essentially a metafile, i.e.
> a stored record of drawing commands. In theory, this lets you run gnuplot
> itself and gnuplot_x11 on different machines. E.g.:
> 
> 	rsh somebox gnuplot scriptfile | gnuplot_x11
> 
> would run gnuplot remotely, but gnuplot_x11 on the local machine. This
> might be useful in setups where X11 traffic is not allowed from the remote
> "somebox" to your local one, or where the remote machine doesn't even have
> X11.
> 
> I don't think anyone in the current team has even the slightest idea how
> often this feature was ever used by anyone, or even if it ever was used at
> all.

I have used a slight variant a lot:

    set term gnuplot_x11
    set output 'movie.gnuplot-x11'
    load 'gnuplot script (probably generated by a perl program) which
          will read gigabytes of data files and produce a 1000-frame movie'
    set output

then copy movie.gnuplot-x11 to another machine (which doesn't have the
data files accessible), and play the movie there via
    gnuplot_x11 <movie.gnuplot-x11

ciao,
 
--
-- Jonathan Thornburg <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"      http://www.aei.mpg.de/~jthorn/home.html
   "It is analogous to saying that if I put a detour sign in the middle of
    the freeway to direct traffic to my shopping mall, that I am obeying
    the traffic sign protocols." -- Henry Minsky, commenting on what was
                                    wrong with Verisign's "Site Finder"

Re: Purpose of xlib terminal ?

[Hans-Bernhard B. <br...@ph...>]

On Sun, 16 Nov 2003, Ethan A Merritt wrote:

> Can someone fill me in on the intended use of the xlib terminal?
> Is it primarily just a debugging aid for x11, or a mechanism for piping
> x11 output to something other than gnuplot_x11?

Not really.  Xlib output is supposed to be to the x11 driver what the EMF
driver would be for the Windows driver.  It's essentially a metafile, i.e.
a stored record of drawing commands. In theory, this lets you run gnuplot
itself and gnuplot_x11 on different machines. E.g.:

	rsh somebox gnuplot scriptfile | gnuplot_x11

would run gnuplot remotely, but gnuplot_x11 on the local machine. This
might be useful in setups where X11 traffic is not allowed from the remote
"somebox" to your local one, or where the remote machine doesn't even have
X11.

I don't think anyone in the current team has even the slightest idea how
often this feature was ever used by anyone, or even if it ever was used at
all.

> 'help set term xlib' leads one to believe that the xlib terminal driver
> is the same as x11 except that the output is controlled by 'set output'.

Exactly.  And at the time that was written, this probably was correct.
Since then, bit-rot has done its work.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Purpose of xlib terminal ?

[Ethan A M. <merritt@u.washington.edu>]

Can someone fill me in on the intended use of the xlib terminal?
Is it primarily just a debugging aid for x11, or a mechanism for piping
x11 output to something other than gnuplot_x11?

'help set term xlib' leads one to believe that the xlib terminal driver is
the same as x11 except that the output is controlled by 'set output'.
Maybe this used to be true, but there are now many options and
capabilities in x11.trm that are not in xlib.trm

It would be trivial to replace the current xlib.trm code with a
simple TERM_TABLE that duplicates the entries in x11.trm except
for term->init, which would set the output device appropriately.
This would be perfect, if the idea is to use it as a debugger for x11.

But if xlib is exists for compatibility with some other display
program (not gnuplot_x11) then maybe it needs to keep its
limited command set?

Or it could be removed altogether, or replaced with a
terminal option in the x11 terminal
	'set term x11 debug'

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: image/binary patch updated

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Friday 14 November 2003 13:31, Ethan Merritt wrote:
>  
>
>>On Friday 14 November 2003 13:36, you wrote:
>>    
>>
>>>That crash you are describing with the
>>>swap bytes, it may be that that is not a problem
>>>with the code, but perhaps the fact that the
>>>internal floating point code for DEC cc can't
>>>handle bogus floating point numbers.
>>>      
>>>
>>But yes, there are various compiler options
>>to treat floating point errors differently.
>>I'll try again with a different set of floating
>>point settings.
>>    
>>
>
>OK.  l've rebuilt everything using IEEE floating
>point rather than the alpha native floating point.
>The crashes go away, and the postscript output
>is rather more informative (attached).
>

Glad that is accounted for.  Interesting problem I didn't anticipate.

>Note in particular that the test plot labeled 
>"Closeup of pixels having grid points ...."
>is missing the lower two boxes. That must mean
>something.... if we only recognized what.
>

The data is still not correctly ASCII85 encoded.  That example
with the close up works because with so little data it happens that
the bad coding ends up being valid ASCII85 characters still.  Of
course, the image is incorrect.

I think I see what the issue is.  It is a bug.  The ASCII85 encoding
uses 4 bytes as the input to its mapping.  That is 32 bits.  It is a
series of shift operations in which a 'long' is filled with bits by shifting
left.  When the long is 4 bytes, successive codings will simply shift
the old value out past the length of the long.  But when a long is
8 bytes, the old value is shifted into the more significant bytes of the
variable which, consequently, makes a mess of the coding.  I will update
this on SourceForge, but if you want a quick fix, search in `post.trm'
for the first use of PS_encode85() and put "tuple4 = 0;" after it.  I.e.,

        PS_encode85(tuple4, tuple5);
        tuple4 = 0;

This will clear the tuple4 value so that garbage isn't shifted upward.

>If you really require some particular floating
>point behavior then you need to figure out some
>way of testing for this and at least issue a warning
>when ./configure is run.
>

I'm going to cede to suggestions from you and the list on this one.
My experience with the innards of floating point numbers in
compilers is minimal.  I just assumed that any binary floating
point numbers read in will translate to some valid number and the
user would recognize that plotted results are invalid.  I hadn't
anticipated the possibility of a program crash.

That leaves the shredded X11 images problem unresolved.  I'll
keep thinking.

Thanks,

Dan

Universal enhanced text mode!

[Ethan M. <merritt@u.washington.edu>]

I have abstracted the enhanced text mode from the postscript
terminal so that it can be used by other terminal types as well.
The core code moves into term.c. Each terminal wanting enhanced
text support must add 3  call-back routines to its TERM_TABLE.=20

Patch is on SourceForge (#842303).
Please check it out before I add it to CVS.

I have added reference implementations for
    post   gd   pdf   x11   dumb

The postscript output is character-for-character identical to
the output the original version.
Implementations for gd, pdf, and x11 are 99% complete.

Implementation of enhanced text for the dumb terminal is
admittedly frivolous, but I wanted to show that the new
mechanism is general enough to apply to any terminal driver.
The commented code for the ENHdumb_ callbacks can serve
as a model for other drivers.

Since the core code is shared, and was already present in
the original postscript driver, adding support to new drivers
does not substantially add to the size of gnuplot.=20
Enabling support for the dumb terminal, for example,
adds only 1500 bytes. More complicated terminals may need=20
larger call-back routines, of course, but the total size increase
of the gnuplot executable after adding the full patch is  about
0.7% on my machine.

A quick demo:

set term dumb enhanced
set title "Dumb is 10^2 less dumb than before"
set label 1 "Sum@_0^{big} fun(x_k)"
set label 1 at -.4, .4
set xrange [-1:0.5]
set xtics nomirror
set ytics nomirror
set tmargin 5
set border 3
plot x*x title "x^2"
#
pause -1


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195