You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(2) |
Mar
(2) |
Apr
(22) |
May
(14) |
Jun
(18) |
Jul
(19) |
Aug
(7) |
Sep
(4) |
Oct
(6) |
Nov
(12) |
Dec
(14) |
2005 |
Jan
(15) |
Feb
(11) |
Mar
(11) |
Apr
(9) |
May
(119) |
Jun
(25) |
Jul
(16) |
Aug
(19) |
Sep
(26) |
Oct
(14) |
Nov
(7) |
Dec
(45) |
2006 |
Jan
(22) |
Feb
(7) |
Mar
(11) |
Apr
(11) |
May
(12) |
Jun
(19) |
Jul
(12) |
Aug
(5) |
Sep
(21) |
Oct
(33) |
Nov
(42) |
Dec
(34) |
2007 |
Jan
(26) |
Feb
(27) |
Mar
(54) |
Apr
(37) |
May
(68) |
Jun
(81) |
Jul
(55) |
Aug
(86) |
Sep
(60) |
Oct
(33) |
Nov
(33) |
Dec
(47) |
2008 |
Jan
(37) |
Feb
(37) |
Mar
(52) |
Apr
(63) |
May
(98) |
Jun
(70) |
Jul
(61) |
Aug
(38) |
Sep
(64) |
Oct
(55) |
Nov
(48) |
Dec
(111) |
2009 |
Jan
(68) |
Feb
(83) |
Mar
(102) |
Apr
(140) |
May
(156) |
Jun
(65) |
Jul
(75) |
Aug
(26) |
Sep
(28) |
Oct
(31) |
Nov
(38) |
Dec
(78) |
2010 |
Jan
(53) |
Feb
(33) |
Mar
(87) |
Apr
(94) |
May
(77) |
Jun
(84) |
Jul
(66) |
Aug
(74) |
Sep
(53) |
Oct
(40) |
Nov
(38) |
Dec
(31) |
2011 |
Jan
(19) |
Feb
(17) |
Mar
(43) |
Apr
(53) |
May
(42) |
Jun
(35) |
Jul
(19) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
2012 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2017 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
(1) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Harald K. <ko...@sc...> - 2004-07-20 15:34:43
|
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... ^^^^^ ^^^^^ |
From: <not...@ss...> - 2004-07-18 23:48:23
|
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. |
From: Yahoo! G. <confirm-s2-Flnw31pL0nNh2OAFpAYsuDNmKik-gnuplot-bugs=<lis...@ya...> - 2004-07-14 01:03:56
|
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/ |
From: Yahoo! G. <confirm-s2-zMM75aGXXVCW5QtoS1QELjJ=mAw-gnuplot-bugs=<lis...@ya...> - 2004-07-13 00:04:56
|
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/ |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-10 13:23:47
|
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. |
From: Claas T. <cla...@sc...> - 2004-07-10 11:39:39
|
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 |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-07 21:27:57
|
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. |
From: <Die...@t-...> - 2004-07-07 20:23:37
|
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---------------------------------------------------------- |
From: Hans-Bernhard B. <br...@ph...> - 2004-07-06 12:01:23
|
[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. |
From: <Ada...@sc...> - 2004-07-06 11:23:39
|
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) |
From: Shigeharu T. <sh...@ie...> - 2004-06-29 11:43:02
|
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 +========================================================+ |
From: Ken C. <jkc...@co...> - 2004-06-29 07:06:03
|
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 |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-27 22:16:27
|
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. |
From: Ken C. <Ken...@co...> - 2004-06-26 03:58:01
|
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 |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-06 15:31:49
|
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. |
From: Wanderson W. <wan...@if...> - 2004-06-04 18:17:48
|
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 |
From: Uwe Z. <uw...@kt...> - 2004-06-02 12:15:44
|
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...] |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-01 23:59:41
|
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. |
From: Uwe Z. <uw...@kt...> - 2004-06-01 18:37:37
|
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. |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-01 14:28:09
|
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. |
From: Uwe Z. <uw...@kt...> - 2004-06-01 14:08:37
|
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. |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-01 13:28:21
|
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. |
From: Uwe Z. <uw...@kt...> - 2004-06-01 13:12:57
|
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". |
From: Uwe Z. <uw...@kt...> - 2004-06-01 13:08:49
|
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. |
From: Hans-Bernhard B. <br...@ph...> - 2004-06-01 12:50:32
|
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. |