gnuplot-bugs — Place to submit bug reports on gnuplot

[Gnuplot-bugs] gnuplot 4.0.0, PDFlib and term/pdf.tfm

[Harald K. <ko...@sc...>]

Hi gnuplot developers!


first, a big thank for that wonderful tool gnuplot !!!! 
I'm using it for many many years now and I still prefere t
because of it's great and simple UI...



I've compiled gnuplot-4.0.0 on various plattforms including PDF support
using PDFlib-Lite-6.0.0, and I had to make a few changes in the sources
for portability (full patch see below).

finally I;ve added a "wish list" as RFC with some ideas below as (5) ...



1) PDFlib-6.0.0 is missing PDF_open_fp()

PDF_open_fp() is no longer supported, only PDF_open_file() is available.
see change in term/pdf.trm below.

for more PDF stuff, please see (4) and (5) below...



2) sequence of "png.trm" and "pdf.trm" in src/term.h:

on some Linux boxes compilation bombs because of the following code 
in pngconf.h of my copy of libpng sources:

	#ifdef PNG_SETJMP_SUPPORTED
	/* This is an attempt to force a single setjmp behaviour on Linux.  If
	 * the X config stuff didn't define _BSD_SOURCE we wouldn't need this.
	 */

	#  ifdef __linux__
	#    ifdef _BSD_SOURCE
	#      define PNG_SAVE_BSD_SOURCE
	#      undef _BSD_SOURCE
	#    endif
	#    ifdef _SETJMP_H
==>	      __png.h__ already includes setjmp.h;
==>	      __dont__ include it again.;
	#    endif
	#  endif /* __linux__ */

changing the ordering in term.h (png before pdf) seems to be the
most portable solution to me (see src/term.h diff below).



3) "char" argument and pre-ANSI-C (K&R) functions without prototypes:

old-style K&R funtions don't really allow to have "char" arguments,
because without correct prototype "char" will be promoted to "int".
so mixing old-style functions and ANSI-C protypes can mess up code
on some plattforms, e.g. HP-UX 10.20:

	cc: "../term/hpljii.trm", line 284: error 1711: Inconsistent parameter list declaration for "HPLJII_putc".
	cc: "term.c", line 2025: error 1711: Inconsistent parameter list declaration for "do_enh_writec".

on other plattforms with gcc I get those warnuings:

      ../term/dumb.trm:556: warning: initialization from incompatible pointer type
      ../term/pdf.trm:1396: warning: initialization from incompatible pointer type
      ../term/x11.trm:1558: warning: initialization from incompatible pointer type
      ../term/x11.trm:1581: warning: initialization from incompatible pointer type

to get rid of the this problem I changed the "char" to "int" argument for do_enh_writec() 
and in pm3d_plot()  (see changes in src/pm3d.c, src/term.c and term/hpljii.trm)

maybe you really should clean up the K&R code and use ANSI-C style 
functions and prototypes everywhere.  maybe it's just to run 
the tool "protoize" from (old?) gcc distributions ?!?



4) PDF output and acroread

maybe you can remember my mail

	Subject: bugs/problems in gnuplot 3.8k (cvs)
	Message-ID: <200...@tu...>
	Date: Fri, 23 Jan 2004 18:36:22 +0100
	From: Harald Koenig <ko...@sc...>
	To: gnu...@li..., gnu...@li...
	
about landscape vs. portrait printing of gnuplot-PDF files with acroread ?


now with gnuplot-4.0.0 and PDFlib-Lite-6.0.0 or PDFlib-6.0.0 the situation
still was the same: acroread prints PDF files from gnuplot by default
on a portrait page with plenty white space above and below the 
landscape-shaped plot.



first I tried to add that "/Rotate 90" entry in the /Page object, 
but that didn't  help at all:-(   btw: you can add options to 
the /Page object using

	PDF_begin_page_ext(myPDF, xmax, ymax, "rotate=90");
	              ^^^^                  ^^^^^^^^^^^^^ 

but then, the plot region still was the same share/position
and only the plot content itself rotated clockwise. so I added
the following code after PDF_begin_page_ext()
  
        PDF_rotate(myPDF, 90);
        PDF_translate(myPDF, 0,-PDF_YMAX/PDF_RESOLUTION);

which undid the clockwise rotation, but now the printing problem
in acrobat was exactly the same as before :-(((



after plenty more PDF decoding and testing I realized, that acroread
uses some "automagic" behaviour:  

if the PDF file/area size fits into the paper size, the plot is 
printed "as is" without optimization to the page share, even if 
"expand small pages to paper size" is selected. that's what happens
to PDF files from gnuplot, as they are 5x3 inch and fit on A4/letter paper.

if the PDF plot is larger (e.g. gnuplot PS output converted with gs to PDF
which gives ~DIN A4 plot), then acroread automagically rotates the plot
and prints landscape !!

now knowing this, I can print gnuplot PDF files nicely my explicitly selecting
"landscape" in the "File -> Page Setup" and I can get ugly prints with plenty
white space for gnuplot PS->PDF files by selection "portrait". 
unfortuneately, this selection of landscape/portrait is not available in 
the print menu, so usually one won't think about that important switch.


so I looked for a "automatic" solution and tried to enlarge the PDF plots from gnuplot. 
unfortuneately the PDF driver uses lots of magic absolut sizes for many
properties like line widths, tick and symbol sizes etc. which don't scale
correctly if I try to increase PDF_XMAX and  PDF_YMAX.

because of that I'm using the 2nd patch to pdf.trm  below which scales 
the plot size only in the PDF_begin_page() call and in the resolution
transformation in PDF_scale() afterwards.

additionally I changed the page size from 5x3 to 5x3.5 inch, resulting
in a plot of 10x7 inch which is more or less compatible with the 
postscript driver output.  the only drawback I've realizes so far is the
"wrong" font size for text which claims to be 6pt while being scaled 
to 12pt (postscript driver defaults to 14 pt).


it would be great if eiher you change the pdf driver to genereate larger
plot sizes (10x7 in, compatible to postscript -- see (5) below) or
at least try to use XMAX or YMAX or some other scalig constant as unit
for other lenghts/widths/sizes  so that it's easy to change the default
plot size.   thanks!




(5) whish list:: PDF vs. postscript/X11 driver output "compatibility"

it would be great, if at least the X11, postscript and PDF drivers would
generate similar/compatible output for the same gnuplot command file
and try match the visual appearence.  that is, they use

- same color sequuence for line types
- same symbol shape sequuence
- same line hashes 
- same page/plot size


right now, only the first 5 colors are similar (not the same),
starting with color #6 things look different:


	color #		X11		postscript R G B		PDF (web colors)
 
	1		red		1 0 0	   red			0xff, 0x00, 0x00	red
	2		green		0 1 0	   green		0x00, 0xc0, 0x00	dark green   
	3		blue		0 0 1	   blue			0x00, 0x80, 0xff	dark blue    
	4		magenta		1 0 1	   magenta		0xc0, 0x00, 0xff	dark magenta 
	5		cyan		0 1 1      cyan			0x00, 0xee, 0xee	cyan         

	6 		dsienna		1 1 0	   yellow		0xc0, 0x40, 0x00	orange       
	7		orange		0 0 0      black		0xee, 0xee, 0x00	yellow       
	8		coral		1 .3 0	   orange red		0x20, 0x20, 0xc0	royal blue   
	9		#1: red		.5 .5 .5   gray	 		0xff, 0xc0, 0x20	goldenrod1   
	10		#2: green		   #1: red		0x00, 0x80, 0x40	SpringGreen4
	11		...			   ...			...   ...   ...		... 			


IMHO at least the first 16 colors for those (and other) drivers 
should [try to] be the same.  using the web_colors table like 
the PDF driver looks like a goo idea to me (to start with ?)...


any comments to get some common behaviour into the gnuplot drivers ? 




and here are my patches as explained above:

------------------------------------------------------------------------------- 
diff -ur orig/gnuplot-4.0.0/src/pm3d.c gnuplot-4.0.0/src/pm3d.c
--- orig/gnuplot-4.0.0/src/pm3d.c	Sat Apr 10 17:55:15 2004
+++ gnuplot-4.0.0/src/pm3d.c	Fri May 14 13:19:58 2004
@@ -53,7 +53,7 @@
 /* Internal prototypes for this module */
 static double geomean4 __PROTO((double, double, double, double));
 static double median4 __PROTO((double, double, double, double));
-static void pm3d_plot __PROTO((struct surface_points *, char));
+static void pm3d_plot __PROTO((struct surface_points *, int));
 static void pm3d_option_at_error __PROTO((void));
 static void pm3d_rearrange_part __PROTO((struct iso_curve *, const int, struct iso_curve ***, int *));
 static void filled_color_contour_plot  __PROTO((struct surface_points *, int));
@@ -304,7 +304,7 @@
 static void
 pm3d_plot(this_plot, at_which_z)
     struct surface_points *this_plot;
-    char at_which_z;
+    int at_which_z;
 {
     int j, i, i1, ii, ii1, from, curve, scan, up_to, up_to_minus, invert = 0;
     int go_over_pts, max_pts;
diff -ur orig/gnuplot-4.0.0/src/term.c gnuplot-4.0.0/src/term.c
--- orig/gnuplot-4.0.0/src/term.c	Tue Apr 13 19:24:02 2004
+++ gnuplot-4.0.0/src/term.c	Fri May 14 13:23:17 2004
@@ -218,7 +218,7 @@
 	     char *fontname, double fontsize, double base, 
 	     TBOOLEAN widthflag, TBOOLEAN showflag, int overprint));
 static void enh_err_check __PROTO((const char *str));
-static void do_enh_writec __PROTO((char c));
+static void do_enh_writec __PROTO((int c));
 
 #ifdef __ZTC__
 char *ztc_init();
@@ -2024,7 +2024,7 @@
 
 static void
 do_enh_writec(c)
-    char c;
+    int c;
 {
     *enhanced_cur_text++ = c;
 }
diff -ur orig/gnuplot-4.0.0/src/term.h gnuplot-4.0.0/src/term.h
--- orig/gnuplot-4.0.0/src/term.h	Tue Apr 13 19:24:02 2004
+++ gnuplot-4.0.0/src/term.h	Fri Jul  2 16:58:25 2004
@@ -345,12 +345,6 @@
 /* portable bit map */
 #include "pbm.trm"
 
-/* Adobe Portable Document Format (PDF) */
-/* NOTE THAT PDF REQUIRES A SEPARATE LIBRARY : see term/pdf.trm */
-#ifdef HAVE_LIBPDF
-# include "pdf.trm"
-#endif
-
 /* NOTE THAT PNG AND JPEG SUPPORT REQUIRE SEPARATE LIBRARIES */
 /* There are 2 flavors of PNG support                                        */
 /* If you are using an old version of libgd in order to get true GIF support */
@@ -363,6 +357,12 @@
 # else
 #  include "png.trm"
 # endif
+#endif
+
+/* Adobe Portable Document Format (PDF) */
+/* NOTE THAT PDF REQUIRES A SEPARATE LIBRARY : see term/pdf.trm */
+#ifdef HAVE_LIBPDF
+# include "pdf.trm"
 #endif
 
 /* postscript */
diff -ur orig/gnuplot-4.0.0/term/hpljii.trm gnuplot-4.0.0/term/hpljii.trm
--- orig/gnuplot-4.0.0/term/hpljii.trm	Tue Apr 13 19:24:33 2004
+++ gnuplot-4.0.0/term/hpljii.trm	Fri May 14 13:24:03 2004
@@ -117,7 +117,7 @@
 #define HPLJII_COURIER fputs("\033(0N\033(s0p10.0h12.0v0s0b3T\033&l6D",gpoutfile)
 
 
-static void HPLJII_putc __PROTO((unsigned int x, unsigned int y, char c, int ang));
+static void HPLJII_putc __PROTO((unsigned int x, unsigned int y, int c, int ang));
 static int hplj_dpp = 4;
 /* bm_pattern not appropriate for 300ppi graphics */
 #ifndef GOT_300_PATTERN
@@ -284,7 +284,7 @@
 static void
 HPLJII_putc(x, y, c, ang)
     unsigned int x, y;
-    char c;
+    int c;
     int ang;
 {
     HPLJII_POP_CURSOR;
diff -ur orig/gnuplot-4.0.0/term/pdf.trm gnuplot-4.0.0/term/pdf.trm
--- orig/gnuplot-4.0.0/term/pdf.trm	Sat Apr 10 17:55:17 2004
+++ gnuplot-4.0.0/term/pdf.trm	Tue Jul 20 15:26:30 2004
@@ -343,7 +343,7 @@
 	myPDF = PDF_new();
 
     /*open new PDF file */ 
-    if (PDF_open_fp(myPDF, gpoutfile) == -1)
+    if (PDF_open_file(myPDF, outstr) == -1)
 	int_error(NO_CARET, "Error:cannot open PDF file .\n");
 
 #ifdef PDF_DONT_COMPRESS
diff -ur orig/gnuplot-4.0.0/term/pdf.trm gnuplot-4.0.0/term/pdf.trm
--- orig/gnuplot-4.0.0/term/pdf.trm	Sat Apr 10 17:55:17 2004
+++ gnuplot-4.0.0/term/pdf.trm	Tue Jul 20 15:26:30 2004
@@ -72,7 +72,7 @@
 
 #define PDF_RESOLUTION  (20)	/* number of terminal pixels per pt */
 #define PDF_XMAX	(5*72*PDF_RESOLUTION) /* 5 inches, 72 pt/inch */
-#define PDF_YMAX	(3*72*PDF_RESOLUTION) /* 3 inches, 72 pt/inch */
+#define PDF_YMAX	(3.5*72*PDF_RESOLUTION) /* 3 inches, 72 pt/inch */
 
 #endif /* TERM_PROTO */
 
@@ -395,9 +395,10 @@
     term->xmax = PDF_XMAX * xsize;
     term->ymax = PDF_YMAX * ysize;
     
-    PDF_begin_page(myPDF, (double)term->xmax / PDF_RESOLUTION,
-		   (double)term->ymax / PDF_RESOLUTION);
-    PDF_scale(myPDF, 1.0/PDF_RESOLUTION, 1.0/PDF_RESOLUTION);
+    PDF_begin_page(myPDF, 2.0 * (double)term->xmax / PDF_RESOLUTION,
+		   2.0 * (double)term->ymax / PDF_RESOLUTION);
+    PDF_scale(myPDF, 2.0/PDF_RESOLUTION, 2.0/PDF_RESOLUTION);
+
     if (title.text && title.text[0])
 	/* a title has been set --> use it as the bookmark name, too */
 	PDF_add_bookmark(myPDF, title.text, 0, 1);
------------------------------------------------------------------------------- 

Harald Koenig
-- 
"I hope to die                                      ___       _____
before I *have* to use Microsoft Word.",           0--,|    /OOOOOOO\
Donald E. Knuth, 02-Oct-2001 in Tuebingen.        <_/  /  /OOOOOOOOOOO\
                                                    \  \/OOOOOOOOOOOOOOO\
                                                      \ OOOOOOOOOOOOOOOOO|//
Harald Koenig                                          \/\/\/\/\/\/\/\/\/
science+computing ag                                    //  /     \\  \
ko...@sc...                            ^^^^^       ^^^^^

[Gnuplot-bugs] Autoreply from SSH

[<not...@ss...>]

Thank you for sending a message to SSH Communications Security Corp.

This e-mail address is not in use anymore. Please re-send your message to 

	ssh.sales at ssh.com

(Please delete the space before and after the "at" letters and also replace 
"at" with @ mark. We are sorry for this inconvenience, but these steps are 
necessary to help us avoid SPAM.)

You can also view our contact information from: 
http://www.ssh.com/company/contact/

Thank you for your interest in SSH products.

Best Regards,
SSH Communications Security Corp.

[Gnuplot-bugs] Please confirm your request to join RayStockwell

[Yahoo! G. <confirm-s2-Flnw31pL0nNh2OAFpAYsuDNmKik-gnuplot-bugs=<lis...@ya...>]

Hello gnu...@li...,

We have received your request to join the RayStockwell 
group hosted by Yahoo! Groups, a free, easy-to-use community service.

This request will expire in 7 days.

TO BECOME A MEMBER OF THE GROUP: 

1) Go to the Yahoo! Groups site by clicking on this link:

   http://groups.yahoo.com/i?i=Flnw31pL0nNh2OAFpAYsuDNmKik&e=gnuplot-bugs%40lists%2Esourceforge%2Enet 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you did not request, or do not want, a membership in the
RayStockwell group, please accept our apologies
and ignore this message.

Regards,

Yahoo! Groups Customer Care

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

 

[Gnuplot-bugs] Please confirm your request to join tom_vacarro

[Yahoo! G. <confirm-s2-zMM75aGXXVCW5QtoS1QELjJ=mAw-gnuplot-bugs=<lis...@ya...>]

Hello gnu...@li...,

We have received your request to join the tom_vacarro 
group hosted by Yahoo! Groups, a free, easy-to-use community service.

This request will expire in 7 days.

TO BECOME A MEMBER OF THE GROUP: 

1) Go to the Yahoo! Groups site by clicking on this link:

   http://groups.yahoo.com/i?i=zMM75aGXXVCW5QtoS1QELjJ-mAw&e=gnuplot-bugs%40lists%2Esourceforge%2Enet 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you did not request, or do not want, a membership in the
tom_vacarro group, please accept our apologies
and ignore this message.

Regards,

Yahoo! Groups Customer Care

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 

 

Re: [Gnuplot-bugs] unset xmtics

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

On Sat, 10 Jul 2004, Claas Thede wrote:

> Once you set the xmtics you can't unset them.

Now that you mention it --- yeah, right.  It's simply not implemented.

I'm on it.

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

[Gnuplot-bugs] unset xmtics

[Claas T. <cla...@sc...>]

Hallo / Hello !

Perhaps you were already told about this bug by someone else, but as I
didn't find anything in the faq I'm writing this mail to you, hoping you
find my English to be understandable.

The problem is the following:
Once you set the xmtics you can't unset them.
"unset xmtics" doesn't work, so "show xmtics" still says that the xmtics are
on (see also the pasted lines at the end of this mail).

For your information: I'm running Gnuplot ...
Version 4.0 patchlevel 0
last modified Thu Apr 15 14:44:22 CEST 2004
System: MS-Windows 32 bit


Yours,
Claas Thede



gnuplot> set xmtics
gnuplot> show xmtics

        tics are IN,    ticslevel is 0.5
        major ticscale is 1 and minor ticscale is 0.5
        x-axis tics:    on border and mirrored on opposite border
          labels are format "% g" and are not rotated
          Months computed automatically
        x2-axis tics:   OFF

gnuplot> unset xmtics
gnuplot> show xmtics

        tics are IN,    ticslevel is 0.5
        major ticscale is 1 and minor ticscale is 0.5
        x-axis tics:    on border and mirrored on opposite border
          labels are format "% g" and are not rotated
          Months computed automatically
        x2-axis tics:   OFF

Re: [Gnuplot-bugs] propably a bug ...

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

On Wed, 7 Jul 2004, Dieter Jurzitza wrote:

> If you want arrows at the axes-labels this only works for non-log axes.

That's not exactly true.  It's not the position that causes that error.
It's the fact that you put the arrow in graph x coordinates, but forgot to
do the same for the head size argument you specified.  You almost
certainly don't want to express the head size in x axis units, yet that's
what your command is doing.

> However, assuming the usage of the "graph" command the logscale setting (to
> me!) seems meaningless:
> graph should refer to a linear scaling from 0 to 1.0 no matter what the actual 
> scaling on the axes might be.

And that's what it does.  The problem is that you did not apply 'graph' 
in all the places necessary.

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

[Gnuplot-bugs] propably a bug ...

[<Die...@t-...>]

Dear listmembers,
I (propably) found a bug in gnuplot:
version: 4.0
OS: SuSE linux 4.0 (or other linux, I think OS does not matter here)

description:
please see attached sample-file error.plt.

If you want arrows at the axes-labels this only works for non-log axes.
However, assuming the usage of the "graph" command the logscale setting (to
me!) seems meaningless:
graph should refer to a linear scaling from 0 to 1.0 no matter what the act=
ual=20
scaling on the axes might be.
If you set logscale i. e. on the x-axes you cannot put an arrow there.
Strange enough this is true for both x- and y-arrows even though (I'd
expect ...) that it should not matter for the x-arrow since there are no
negative values for x then.

See example I attached. Maybe I am on the wrong track ...

By the way: a chance to reproucably position arrows left and right of the
axes centered to the labeling would be a dream ... :-)

Many thanks for a nice program,
take care



Dieter Jurzitza

=2D-=20
=2D----------------------------------------------------------

                               |
                                \
                 /\_/\           |
                | ~x~ |/-----\   /
                 \   /-       \_/
  ^^__   _        /  _  ____   /
 <=B0=B0__ \- \_/     |  |/    |  |
  ||  ||         _| _|    _| _|

if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
=2D----------------------------------------------------------

Re: [Gnuplot-bugs] Multiplot messing up label line spacing, Also: set size working incorrectly

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

[Limiting this to -bugs...]

On Tue, 6 Jul 2004 Ada...@sc... wrote:

> Is there any way to stop multiplot having this annoying effect?  The 'key'
> line spacing can be adjusted with 'spacing' but I can't find a similar
> option for 'label'.

You'll have to give a more specific example demonstrating this problem.

> Also:  the 'set size' function for each additional plot seems to be working
> incorrectly.  For example:
> 
> ...
> set size 1.0,1.0
> set origin 0,0
> set multiplot
> set size 1.0,0.5
> set origin 0,0
> plot <file>
> ...
> 
> I thought the plot here should take up the whole width (1.0) and half the
> height (0.5), however, any value below 1.0 for the y component of 'set
> size' results in the y axis being reversed.  

Not on my box here it doesn't, but that may be because I'm using the
latest CVS version.

You didn't by any coincidence make that X11 window quite small, did you?
Smaller than 200 pixels in height, say?  There's a known problem where the
y axis would flip over if there simply wasn't enough space to do the plot
in, with the given parameters (margins, presence of axis labels, title,
...).


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

[Gnuplot-bugs] Multiplot messing up label line spacing, Also: set size working incorrectly

[<Ada...@sc...>]

Hi, I wondered whether you might be able to help me with something?

I am trying to use gnuplot's multiplot ability to plot more than one set of
axes in the same window.  I would like to have several rows of header
information on my graph.

I have used 'label' to add the header information to the graph (and
extented the top margin to give it space).

When using a normal 'plot' (ie. not multiplot) the line spacing of the
header is fine and everything fits neatly into the window.  As soon as I
try and use multiplot, the line spacing of the header increases (and the
key line spacing does too), and therefore the header takes up far to much
room, leaving the graph itself with much less space.

Is there any way to stop multiplot having this annoying effect?  The 'key'
line spacing can be adjusted with 'spacing' but I can't find a similar
option for 'label'.

Also:  the 'set size' function for each additional plot seems to be working
incorrectly.  For example:

...
set size 1.0,1.0
set origin 0,0
set multiplot
set size 1.0,0.5
set origin 0,0
plot <file>
...

I thought the plot here should take up the whole width (1.0) and half the
height (0.5), however, any value below 1.0 for the y component of 'set
size' results in the y axis being reversed.  If the value is set to 1 it
seems to take up the least room, whereas if it is set to 0.1 it takes up
more than the entire window with the axis reversed as well!!  (values above
1.0 seem to behave as I would expect the values between 0 and 1 to) Do you
have any idea what is going on here?

The 'set size' problem can at least be worked around, it is the line
spacing issue that is really bugging me.

Thankyou very much in advance.

Adam C.

PS - I am using terminal type X11 (gnuplot version 4.0 patchlevel 0)

[Gnuplot-bugs] problem for 'set arrow ... rto ...'

[Shigeharu T. <sh...@ie...>]

shige 06/29 2004
----------------

I found a problem of gnuplot-4.0.0:

 gnuplot> set arrow from 1,2 rto 0.5,0.5
 gnuplot> set arrow from 1,2 to 0.5,0.5 
 gnuplot> show arrow

        arrow 1, linetype 1, linewidth 1.000  nofilled back
          from (1, 2, 0) to (0.5, 0.5, 0)
        arrow 2, linetype 1, linewidth 1.000  nofilled back
          from (1, 2, 0) to (0.5, 0.5, 0)

that is, the behavior for "rto" is the same as for "to". 
The following small patch may fix it.

----- From here -----
*** gnuplot-org/src/set.c	Wed May  5 01:58:01 2004
--- gnuplot/src/set.c	Tue Jun 29 20:25:58 2004
***************
*** 675,686 ****
  	/* get end or relative end position */
  	if (equals(c_token, "to") || equals(c_token,"rto")) {
  	    if (set_end) { duplication = TRUE; break; }
  	    c_token++;
  	    if (END_OF_COMMAND)
  		int_error(c_token, "end coordinates expected");
  	    /* get coordinates */
  	    get_position(&epos);
! 	    relative = (equals(c_token,"rto")) ? TRUE : FALSE;
  	    set_end = TRUE;
  	    continue;
  	}
--- 675,687 ----
  	/* get end or relative end position */
  	if (equals(c_token, "to") || equals(c_token,"rto")) {
  	    if (set_end) { duplication = TRUE; break; }
+ 	    relative = (equals(c_token,"rto")) ? TRUE : FALSE;
  	    c_token++;
  	    if (END_OF_COMMAND)
  		int_error(c_token, "end coordinates expected");
  	    /* get coordinates */
  	    get_position(&epos);
! 	    /* relative = (equals(c_token,"rto")) ? TRUE : FALSE; */
  	    set_end = TRUE;
  	    continue;
  	}
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

[Gnuplot-bugs] Re: libgd png(NEW) truetype font bug with multiplot/replot

[Ken C. <jkc...@co...>]

Hans-Bernhard Broeker <broeker <at> physik.rwth-aachen.de> writes:

> On Fri, 25 Jun 2004, Ken Corson wrote:
> 
> >    I have become rather fond of GnuPlot !! However, there is one bug
> > that is currently irritating me - when using the png(NEW/libgd) driver
> > to graph multiple variables, using multiplot and replot, the labels
> > all get redrawn on each replot. 
> 
> Well, as the saying goes, don't do that then.  You're almost 
> certainly  abusing multiplot here.  You can plot multiple datasets
> in a single command without resorting to mulitplot.  It'll actually
> make the job simpler, too.

Hans-Bernhard,
  Thank you! Consolidating my plots to a single command produced exactly
what I was hoping to generate !! Now I absolutely adore GnuPlot, and 
there isn't a single issue irritating me :)

Ken

Re: [Gnuplot-bugs] libgd png(NEW) truetype font bug with multiplot/replot

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

On Fri, 25 Jun 2004, Ken Corson wrote:

>    I have become rather fond of GnuPlot !! However, there is one bug
> that is currently irritating me - when using the png(NEW/libgd) driver
> to graph multiple variables, using multiplot and replot, the labels
> all get redrawn on each replot. 

Well, as the saying goes, don't do that then.  You're almost 
certainly  abusing multiplot here.  You can plot multiple datasets
in a single command without resorting to mulitplot.  It'll actually
make the job simpler, too.

The overdraws happen independent of the terminal driver --- only the
consequences would vary, since most drivers don't draw their text
antialiased.

If you absolutely have to use multiplot, turn off all decorations after 
the first one of them which you don't want output repeatedly.  You'll
probably have to fix the margins to avoid the layout changing halfway
down the road.

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

[Gnuplot-bugs] libgd png(NEW) truetype font bug with multiplot/replot

[Ken C. <Ken...@co...>]

Hello,
   I have become rather fond of GnuPlot !! However, there is one bug
that is currently irritating me - when using the png(NEW/libgd) driver
to graph multiple variables, using multiplot and replot, the labels
all get redrawn on each replot. When using antialiased truetype fonts
this causes the semi-transparent pixels to be redrawn over themselves,
which darkens them to the incorrect shade of darkness. To replicate,
plot four graphs, and provide a title for each one. The first title
will be drawn 4 times, the 2nd 3 times, the 3rd 2 times, and the last
title will be rendered properly. The resulting text looks obviously
wrong, in a blocky sort of way. I am using 10 point tahoma. The larger
the pointsize, the less obvious the problem becomes.
   If I have not expressed the problem sufficiently, please let me
know. I have not confirmed (by reading the source) that multiple
renderings for a single text string is the precise cause, but it seems
the most likely explanation. Perhaps the drawing method for png(NEW),
with multiplot and replot, should be revisited ? Could this affect any
other drivers as well ?
   I don't want to overcommit myself, but I would be glad to assist in
fixing this issue, if possible. I did not find any previous mentioning
in the mailing lists.

Thank you!
- Ken Corson

Re: [Gnuplot-bugs] bugs using fit

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

On Fri, 4 Jun 2004, Wanderson Wanzeller wrote:

[...]
> Final set of parameters            Asymptotic Standard Error
> =======================            ==========================
> 
> a               = 0.000550667      +/- 0.001319     (239.5%)
> b               = 27.5771          +/- 4.699        (17.04%)
> c               = 0.0268601        +/- 0.009831     (36.6%)

These results contain hints of significant trouble already: notice the
relative error on 'a' being extremely large?  That's because 'a' and 'b'
are so hugely different (by 5 orders of magnitude) that it hurts the
performance of the fitting code.  You had better redefine the parameters
to make them have roughly the same size.

[...]
> gnuplot> fit [1:16] g(x) 'omegQ_25bt.dat' using 1:2:3 via a,b,c
[...]
> Final set of parameters            Asymptotic Standard Error
> =======================            ==========================
> 
> a               = 0.000550667      +/- nan          (nan%)
> b               = 27.5771          +/- nan          (nan%)
> c               = 0.0268601        +/- nan          (nan%)

The reason for this is evident if you look into the datafile: the first
few datapoints claim to have an error of exactly zero.  That's physically
impossible, and disrupts the result.  You'll have to remove those
datapoints from the fit, either by changing the file itself or by 
using datapoint selection methos offered by gnuplot (the 'every' option, 
a restriction of the x or y range, or a filtering 'using' specification).


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

[Gnuplot-bugs] bugs using fit

[Wanderson W. <wan...@if...>]

Dear,


I tried using fit function in gnuplot version 4.0 patchlevel 0 (linux debia=
n),=20
but something strange happen.

=46rist I define a function
gnuplot> g(x) =3D a*exp(-b/x) +c*exp(-2*b/x)

and make the fit
gnuplot> fit [1:16] g(x) 'omegQ_25bt.dat'  via a,b,c
=2E . . . .=20
degrees of freedom (ndf) : 13
rms of residuals      (stdfit) =3D sqrt(WSSR/ndf)      : 2.17102e-05
variance of residuals (reduced chisquare) =3D WSSR/ndf : 4.71334e-10

=46inal set of parameters            Asymptotic Standard Error
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D      =
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

a               =3D 0.000550667      +/- 0.001319     (239.5%)
b               =3D 27.5771          +/- 4.699        (17.04%)
c               =3D 0.0268601        +/- 0.009831     (36.6%)


correlation matrix of the fit parameters:

               a      b      c     =20
a               1.000=20
b               0.982  1.000=20
c               0.936  0.985  1.000=20

The file omegQ_25bt.dat have 3 data columns:  x, f(x), error in f(x) , then=
 I=20
want use this error, I put "using 1:2:3" in commannd line

gnuplot> fit [1:16] g(x) 'omegQ_25bt.dat' using 1:2:3 via a,b,c
degrees of freedom (ndf) : 13
rms of residuals      (stdfit) =3D sqrt(WSSR/ndf)      : inf
variance of residuals (reduced chisquare) =3D WSSR/ndf : inf

=46inal set of parameters            Asymptotic Standard Error
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D      =
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

a               =3D 0.000550667      +/- nan          (nan%)
b               =3D 27.5771          +/- nan          (nan%)
c               =3D 0.0268601        +/- nan          (nan%)

correlation matrix of the fit parameters:

               a      b      c     =20
a                 nan=20
b                 nan    nan=20
c                 nan    nan    nan=20

OK!!! is no possible make fit that way, than I put off  "using 1:2:3",=20
however, the results change:=20

gnuplot> fit [1:16] g(x) 'omegQ_25bt.dat' via a,b,c

degrees of freedom (ndf) : 13
rms of residuals      (stdfit) =3D sqrt(WSSR/ndf)      : nan
variance of residuals (reduced chisquare) =3D WSSR/ndf : nan

=46inal set of parameters            Asymptotic Standard Error
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D      =
      =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D

a               =3D nan              +/- nan          (nan%)
b               =3D nan              +/- nan          (nan%)
c               =3D 0.0268601        +/- nan          (nan%)


correlation matrix of the fit parameters:

               a      b      c     =20
a                 nan=20
b                 nan    nan=20
c                 nan    nan    nan=20


This is a bug, I think,


That's all

Thanks


=2D-=20
=2D-------------------------------------------------------------------

Wanderson Gon=E7alves Wanzeller

Instituto de F=EDsica Te=F3rica - IFT / UNESP

Rua Pamplona, 145=20
CEP: 01405-900
S=E3o Paulo - SP

Re[4]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

Hi Hans-Bernhard,

you are right, right and right. Sorry for taking up your time and
bandwidth with something which mainly was a common user error...

Still, "set datafile separator" is _not_ listed among the functions
you get when you simply type "set" on the GnuPlot 4 command line,
which was the first thing I tried, long before looking into the
documentation.

Your name got added to the address line by my email program (TheBat!)
by default.

   Uwe.


Wednesday, June 2, 2004, 1:58:58 AM, you wrote:

HBB> On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

>> Yes, that was the index I was talking about. A while ago I tried to
>> work with Windows help files myself and know how weird these things
>> are... ;-}

HBB> Now I'm on a Windows box, and it turns out it's listed right there between
HBB> "set datafile missing" and "set date_specifiers".  It's also available
HBB> just as "separator".

HBB> In other words, you tried exactly those two out of four possible keywords
HBB> it might have been indexed under, where it's not.  ;-)

HBB> [And, for the records, gnuplot-bugs@ is not *my* personal mail address, so
HBB> it kind of misses the point putting my name on it...]

Re[3]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

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

On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

> Yes, that was the index I was talking about. A while ago I tried to
> work with Windows help files myself and know how weird these things
> are... ;-}

Now I'm on a Windows box, and it turns out it's listed right there between
"set datafile missing" and "set date_specifiers".  It's also available
just as "separator".

In other words, you tried exactly those two out of four possible keywords
it might have been indexed under, where it's not.  ;-)

[And, for the records, gnuplot-bugs@ is not *my* personal mail address, so
it kind of misses the point putting my name on it...]

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

Re[3]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

Hello Hans-Bernhard,

Tuesday, June 1, 2004, 4:27:16 PM, you wrote:

HBB> On Tue, 1 Jun 2004, Uwe Zimmermann wrote:


>> >>   set datafile separator
>> >> 
>> >> is not listed in the help, 
>> 
>> HBB> Not listed *where* in "the help"?  And why should it have appeared right
>> HBB> there?
>> 
>> 
>> in the index between "datafile matrix" and "datafile smooth"  or
>> between "commands set contour" and "commands set decimalsign".

HBB> For the record: that's the index of the Win32 wgnuplot.hlp file, right?

Yes, that was the index I was talking about. A while ago I tried to
work with Windows help files myself and know how weird these things
are... ;-}


Thanks a lot!

   Uwe.

Re[2]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

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

On Tue, 1 Jun 2004, Uwe Zimmermann wrote:


> >>   set datafile separator
> >> 
> >> is not listed in the help, 
> 
> HBB> Not listed *where* in "the help"?  And why should it have appeared right
> HBB> there?
> 
> 
> in the index between "datafile matrix" and "datafile smooth"  or
> between "commands set contour" and "commands set decimalsign".

For the record: that's the index of the Win32 wgnuplot.hlp file, right?

> I have to admit upon closer inspection that it _is_ indeed listed
> between "set datafile missing" and "set date specifiers", I wonder why
> the index is this much cluttered with similar entries at different
> positions...?

I guess this is caused by the gnuplot.doc not containing these nodes in
alphabetically sorted order, or by some slight mistake in the structure of
node header lines in gnuplot.doc, the file all the various editions of the
documentation are generated from.

I don't fully understand how the Index of the .hlp is generated from the 
RTF file, which in turn is generated from gnuplot.doc, so it's hard to 
see what's wrong there.

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

Re[2]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

Hello Hans-Bernhard,

Tuesday, June 1, 2004, 3:20:42 PM, you wrote:

HBB> On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

>> Hi Hans-Bernhard,
>> 
>> thanks for this incredibly fast reply!
>> Yes I mixed up versions, partly because
>> 
>>   set datafile separator
>> 
>> is not listed in the help, 

HBB> Not listed *where* in "the help"?  And why should it have appeared right
HBB> there?


in the index between "datafile matrix" and "datafile smooth"  or
between "commands set contour" and "commands set decimalsign".

I have to admit upon closer inspection that it _is_ indeed listed
between "set datafile missing" and "set date specifiers", I wonder why
the index is this much cluttered with similar entries at different
positions...?

Uwe.

Re: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

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

On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

> Hi Hans-Bernhard,
> 
> thanks for this incredibly fast reply!
> Yes I mixed up versions, partly because
> 
>   set datafile separator
> 
> is not listed in the help, 

Not listed *where* in "the help"?  And why should it have appeared right
there?

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

Re[2]: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

Hi Hans-Bernhard,

thanks for this incredibly fast reply!
Yes I mixed up versions, partly because

  set datafile separator

is not listed in the help, nor in the list of options when you write

  set

on a Gnuplot 4 command line either...

See my second message a minute ago, I solved the problem by using the
datafile separator again...

   Uwe.
   

Tuesday, June 1, 2004, 1:35:53 PM, you wrote:

HBB> On Tue, 1 Jun 2004, Uwe Zimmermann wrote:

HBB> [...]
>> plot          \
>>      '030910alogg.csv' \
>>         every 1:::0::0 \
>>         using ($1<4700? $1/60.0-60.0:1/0):($2) \
>>           '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\

HBB> That's 6 %lf specifiers...

>> but adding another column to the format specifier crashes Gnuplot on
>> Win32 (WinXP sp1+updates):
HBB> [...]
>>   
>> "%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\

HBB> Now it's 8 %lf specifiers, and that's the cause of the problem.  None of
HBB> gnuplot's plot styles uses more than 7 'using' specifiers, so the format
HBB> string isn't expected to contain more than 7 instances of %lf.  You should
HBB> replace the %lf for those columns you aren't going to actually use by
HBB> %*lf, which parses a number but then ignores it.

HBB> So the real bugs are two-fold: this limitation should be documented in
HBB> 'help using', and exceeding the limit should yield an error message rather
HBB> than crash gnuplot.  I'll see how this can be fixed.

>> Earlier I was able to plot this same datafile with GnuPlot 3.7x where
>> the column separator could be redefined to be a comma instead of a
>> whitespace...

HBB> You're mixing up versions here, I think.  I'm quite positive none of the
HBB> officially released 3.7x versions had such an option; i.e. yours must have
HBB> been a modified one.  gnuplot 4.0, OTOH, does have this option.  See "help
HBB> separator".

Re: [Gnuplot-bugs] Gnuplot 4.0 Win32 crashes on plot from file

[Uwe Z. <uw...@kt...>]

I might have been a bit confuse concerning the

  set datafile separator ","

since it is not mentioned in the index of the Gnuplot 4.0 help file.
The example given below works fine now again without giving the format
specifier in the using directive but by switching to comma as
separator character.

It appears that my newsreader treated the data file lines badly, so I
attach a sample data file...

    Uwe.

    

UZ> Gnuplot 3.8i and 4.0 both crash while plotting a data file using a
UZ> format specifier on a data file. The data file has 21 comma separated
UZ> columns where every third column is a text formated date (which I
UZ> ignore):

UZ> #101(Time stamp),101(Seconds),101(C),102(Time


UZ> a minimum sample which still works:
UZ> ------------------------
UZ> reset
UZ> set nologscale y

UZ> set xrange [-20:20]
UZ> set autoscale y

UZ> plot          \
UZ>      '030910alogg.csv' \
UZ>         every 1:::0::0 \
UZ>         using ($1<4700? $1/60.0-60.0:1/0):($2)
UZ> '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\
UZ>         axes x1y1 \
UZ>         title 'center temp.' \
UZ>         with lines linewidth 4 \
UZ>     ;
UZ> ------------------------

UZ> but adding another column to the format specifier crashes Gnuplot on
UZ> Win32 (WinXP sp1+updates):


UZ> ------------------------
UZ> reset
UZ> set nologscale y

UZ> set xrange [-20:20]
UZ> set autoscale y

UZ> plot          \
UZ>      '030910alogg.csv' \
UZ>         every 1:::0::0 \
UZ>         using ($1<4700? $1/60.0-60.0:1/0):($2)
UZ> '"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf,"%*[^"]",%lf,%lf'\
UZ>         axes x1y1 \
UZ>         title 'center temp.' \
UZ>         with lines linewidth 4 \
UZ>     ;
UZ> ------------------------

UZ> ...independently on which pair of columns I select to read.

UZ> Earlier I was able to plot this same datafile with GnuPlot 3.7x where
UZ> the column separator could be redefined to be a comma instead of a
UZ> whitespace...

UZ> Any ideas?

UZ>    Uwe.

[Gnuplot-bugs] Re: gnuplot bug

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

On Tue, 25 May 2004, Christopher Jarzynski wrote:

> within gnuplot.  You can see that the histogram is screwed up.  This is 
> not a one-time event: I run into this sort of thing repeatedly when using 
> the histeps option.

I can't seem to reproduce this here, but see below.

> Finally, "GnuplotVersion" is the notice that appears when I run gnuplot; 
> this gives the version, operation system, and so forth.

That version screen indicates you're using a now outdated 3.8 development
release.  Could you re-try this with the release version 4.0?

At least one major bug in handling of 'histeps' was fixed between 3.8i
and 4.0:

        * src/graphics.c (histeps_compare): There was a wrong comparison
        returned by this qsort-called routine, which caused 'plot with
        histeps' buggy.

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