Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2004-10-18 13:11:14
|
Currently, the following code with a macro for generating labels works:
F(x)=sprintf("set label 1000+%i 'result %i' at %g,%g", x,x,x,x)
A=F(1)
@A
A=F(-1)
@A
plot x
Would it be possible to execute C-like macros:
@(F(1))
? I would like this.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-26 00:52:17
|
On Monday 18 October 2004 06:11 am, Petr Mikulik wrote: > > Would it be possible to execute C-like macros: > @(F(1)) Probably it would be @F(1), where F is an existing string-valued function. But yes, that should be possible. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 08:31:50
|
I'm running into some quirks with the pdf terminal that I can't recall in the past. I returned to some octave code and got some crashes where there were none before. The PostScript and X11 terminals still work fine with the script in question. Here is one that I discovered in playing around with gnuplot. Generate a plot to the PDF terminal without having defined the output file: gnuplot> set terminal pdf Terminal type set to 'pdf' Options are 'noenhanced fname 'Helvetica' fsize 6 linewidth 1.0 ' gnuplot> plot x gnuplot> set output PDFlib runtime error: Must call PDF_get_buffer() after PDF_close() Obviously, what I've done above is an incorrect procedure. However, it would be nice if gnuplot not crash after issuing an appropriate error message. I get a different PDFlib error in Octave. Think I've found the problem with a few number of gnuplot commands: gnuplot> set terminal pdf Terminal type set to 'pdf' Options are 'noenhanced fname 'Helvetica' fsize 6 linewidth 1.0 ' gnuplot> set output 'junk.pdf' gnuplot> set bmargin 0 gnuplot> plot x PDFlib value error: floating point value too large in pdf_ftoa (Setting bmargin to zero makes sense in multiplot mode.) Now, if I try: set term pdf set output 'junk.pdf' set bmargin 0 set xtics offset 0,graph 0.5 plot x set output things work fine. And using "set xtics offset 0,graph -0.5" in the above (which should result in the tic text off the PDF plot area) causes the same crash with pdf_ftoa. So the problem may be placing text partially or fully off the screen... or perhaps not the screen, but the graph area... not sure. Ethan, it has been several months since I've used the particular Octave script that leads to this problem, so I'm sure there've been many changes since that time and likely won't recall anything having changed, but any thoughts? Can I help pin this down? I just tried: set term pdf set output 'junk.pdf' set xtics offset 0,graph -0.5 plot x set output and that fails too, so the "bmargin 0" has nothing to do with the problem. Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 08:53:11
|
Daniel J Sebald wrote: > I'm running into some quirks with the pdf terminal that I can't recall > in the past. I returned to some octave code and got some crashes > where there were none before. The PostScript and X11 terminals still > work fine with the script in question. ./configure log shows nothing aberant with pdflib. Perhaps it is a bug in pdflib. The version of pdflib.h I have is: /* $Id: pdflib.h,v 1.39.2.11 2002/01/23 15:40:42 rjs Exp $ #define PDFLIB_MAJORVERSION 4 /* PDFlib major version number */ #define PDFLIB_MINORVERSION 0 /* PDFlib minor version number */ #define PDFLIB_REVISION 2 /* PDFlib revision number */ #define PDFLIB_VERSIONSTRING "4.0.2" /* The whole bunch */ |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-26 15:55:08
|
On Tuesday 26 October 2004 01:31 am, Daniel J Sebald wrote:
> I'm running into some quirks with the pdf terminal that I can't recall
> in the past. I returned to some octave code and got some crashes where
> there were none before. The PostScript and X11 terminals still work
> fine with the script in question.
Please see also bug #1039296 "PDFlib Lite 6 output is broken for pipes, stdout"
The problem is that PDFlib changed substantially from version 5
to version 6. In an attempt to satisfy both, Hans-Bernhard changed pdf.trm
2004-07-08 Hans-Bernhard Broeker <br...@ph...>
* term/pdf.trm (PDF_init): Call PDF_open_file() instead of
no longer existing function PDF_open_fp().
But at the current state of the code, neither version of PDFlib is
entirely happy.
> Here is one that I discovered in playing around with gnuplot. Generate
> a plot to the PDF terminal without having defined the output file:
>
> gnuplot> set terminal pdf
> Terminal type set to 'pdf'
> Options are 'noenhanced fname 'Helvetica' fsize 6 linewidth 1.0 '
> gnuplot> plot x
> gnuplot> set output
> PDFlib runtime error: Must call PDF_get_buffer() after PDF_close()
>
> Obviously, what I've done above is an incorrect procedure. However, it
> would be nice if gnuplot not crash after issuing an appropriate error
> message.
>
>
> I get a different PDFlib error in Octave. Think I've found the problem
> with a few number of gnuplot commands:
>
> gnuplot> set terminal pdf
> Terminal type set to 'pdf'
> Options are 'noenhanced fname 'Helvetica' fsize 6 linewidth 1.0 '
> gnuplot> set output 'junk.pdf'
> gnuplot> set bmargin 0
> gnuplot> plot x
> PDFlib value error: floating point value too large in pdf_ftoa
>
> (Setting bmargin to zero makes sense in multiplot mode.) Now, if I try:
>
> set term pdf
> set output 'junk.pdf'
> set bmargin 0
> set xtics offset 0,graph 0.5
> plot x
> set output
>
> things work fine. And using "set xtics offset 0,graph -0.5" in the
> above (which should result in the tic text off the PDF plot area) causes
> the same crash with pdf_ftoa. So the problem may be placing text
> partially or fully off the screen... or perhaps not the screen, but the
> graph area... not sure.
>
> Ethan, it has been several months since I've used the particular Octave
> script that leads to this problem, so I'm sure there've been many
> changes since that time and likely won't recall anything having changed,
> but any thoughts? Can I help pin this down?
>
> I just tried:
>
> set term pdf
> set output 'junk.pdf'
> set xtics offset 0,graph -0.5
> plot x
> set output
>
> and that fails too, so the "bmargin 0" has nothing to do with the problem.
>
> Dan
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-26 17:35:42
|
Daniel J Sebald wrote: [...] > PDFlib runtime error: Must call PDF_get_buffer() after PDF_close() > > Obviously, what I've done above is an incorrect procedure. Not necessarily. It's perfectly feasible to run gnuplot some_script > output.pdf so you shouldn't be forced to use 'set output'. The error in this case is in pdf.trm. It's apparently unaware of this limitation of PDFlib. > However, it would be nice if gnuplot not crash after issuing an > appropriate error message. That's not gnuplot's decision, I'm afraid. The crash happens deliberately, and inside PDFlib: it calls abort(). [...] > things work fine. And using "set xtics offset 0,graph -0.5" in the > above (which should result in the tic text off the PDF plot area) > causes the same crash with pdf_ftoa. So the problem may be placing > text partially or fully off the screen... Exactly. PDFlib refuses to have coordinates outside the output page boundaries. Part of the problem is that gnuplot doesn't always clip to the page. Now, in some terminals, notable PostScript, it actually makes sense to do have elements outside the "page", so maybe gnuplot shouldn't do that. But in that case, terminal drivers like pdf.trm and those writing bitmap files will have to do their own clipping. Maybe yet another terminal driver flag bit for "coordinates must be clipped to page"? Another possible ingredient to this is the infamous signed vs. unsigned confusion that infests practically all of gnuplot. > and that fails too, so the "bmargin 0" has nothing to do with the > problem. It does indirectly, by pushing the xtics to a place outside the page. |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 18:01:17
|
Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > >> things work fine. And using "set xtics offset 0,graph -0.5" in the >> above (which should result in the tic text off the PDF plot area) >> causes the same crash with pdf_ftoa. So the problem may be placing >> text partially or fully off the screen... > > > Exactly. PDFlib refuses to have coordinates outside the output page > boundaries. Part of the problem is that gnuplot doesn't always clip to > the page. Now, in some terminals, notable PostScript, it actually makes > sense to do have elements outside the "page", so maybe gnuplot shouldn't > do that. But in that case, terminal drivers like pdf.trm and those > writing bitmap files will have to do their own clipping. Nice routines do the clipping at the lowest levels. (Perhaps there is a compilation flag in the PDF libraries that control ignore/abort...) > Maybe yet > another terminal driver flag bit for "coordinates must be clipped to > page"? Not a great solution. > Another possible ingredient to this is the infamous signed vs. unsigned > confusion that infests practically all of gnuplot. That is what first came to mind for me. I'll take a look this evening and see if I can identify just exactly what's going on. Looking closely at that error message: PDFlib value error: floating point value too large in pdf_ftoa makes me wonder now. They wouldn't say "too large" if in fact they meant "negative" as the source of the problem. So I think you are right. Thanks, Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 19:02:23
|
Daniel J Sebald wrote:
>> Another possible ingredient to this is the infamous signed vs. unsigned
>> confusion that infests practically all of gnuplot.
>
>
> makes me wonder now. They wouldn't say "too large" if in fact they
> meant "negative" as the source of the problem. So I think you are right.
I suspect that may be it. The PDF library seems to be robust on the
placement of text partially off the top of the canvas. Also, the
placement of tics far off the top:
set xtics offset 0,graph 10
causes no problems for PDFlib.
I think I see the issue now... what you all were probably talking about
but I paid no attention. In the terminal directory, the .trm files all
have "unsigned" for coordinates, e.g.,
TERM_PUBLIC void
PDF_put_text (unsigned int x, unsigned int y, const char *str)
So, the question is, how is it that the PostScript terminal *works
properly*? Because it shouldn't. It works because it is printing the
unsigned numbers as signed:
sprintf(abso, "%d %d M\n", x, y);
sprintf(rel, "%d %d R\n", dx, dy);
So, the importance of the signed/unsigned issue isn't until its use.
(Conversion from signed int to unsigned int or vice versa doesn't do
anything. Only when it is interpretted is it important.) The
PDF_put_text fails because it has to do the conversion:
double h = x, v = y;
near the top.
OK. I'm getting the feeling this is case of someone having to go
through the pain of changing all those "unsigned" coordinate values
inside the terminal drivers to "signed". At least I don't think it
should wreck any working behavior. It can only make bad behavior better.
If that's the case. I'd suggest someone announce "I'm going to do this
huge patch today, so nobody change anything in CVS for the day". Then
after that, we'll all shake the bugs out of the thing.
...
And I just tried a fix that sort of confirms the problem. Inside the
PDF terminal driver, I made the following change to the first few lines
and the PDFlib abort goes away:
TERM_PUBLIC void
PDF_put_text (unsigned int ux, unsigned int uy, const char *str)
{
char *alignment = NULL;
int x = ux, y = uy;
double h = x, v = y;
If people are happy with that as a fix, I'm fine with it too. [Or it
could be just
double h = (signed) x, v = (signed) y;
if x and y are used no further down the road.] Whether it says "signed"
or "unsigned" in the function, no big deal to me. However, who knows if
all compilers behave the same regarding the signed/unsigned conversion.
Dan
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-26 19:20:14
|
On Tuesday 26 October 2004 12:30 pm, Daniel J Sebald wrote: > > I think I see the issue now... what you all were probably talking about > but I paid no attention. In the terminal directory, the .trm files all > have "unsigned" for coordinates, e.g., It isn't just the *.trm files. In fact I think it is reasonable for the terminal drivers to receive unsigned coordinates. The problem comes before that. Didn't we have this discussion already? All the internal routines convert coordinates to (unsigned int). Unfortunately sometimes they convert too soon, i.e. before clipping. Harald Harders and I have been slowly switching the lower-level routines over to use integer or double coordinates, and adding proper clipping code on top of them. It should now be working for the newer plot styles (with labels, with filledcurves between, with vectors) but not yet for all of the older plot styles. > OK. I'm getting the feeling this is case of someone having to go > through the pain of changing all those "unsigned" coordinate values > inside the terminal drivers to "signed". At least I don't think it > should wreck any working behavior. It can only make bad behavior better. > It is messier than it ought to be because of the way that inverted axis ranges are implemented. Every test for out-of-bounds has to allow for the possibility that the axes limits are stored in reverse order. I'm inclined to say it would be better to change that first, and only afterwards worry about adding clipping code everywhere. But I am not familiar with the history of the axis code, so I don't know all the places that would be affected. > If people are happy with that as a fix, I'm fine with it too. [Or it > could be just > > double h = (signed) x, v = (signed) y; Doesn't work. It only catches the cases that are out of bounds by virtue of having gone negative. It doesn't catch all the other cases of improper clipping. The proper fix lies in the clipping code, not the individual drivers. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-26 19:33:17
|
Ethan Merritt wrote: >On Tuesday 26 October 2004 12:30 pm, Daniel J Sebald wrote: > > >>I think I see the issue now... what you all were probably talking about >>but I paid no attention. In the terminal directory, the .trm files all >>have "unsigned" for coordinates, e.g., >> >> > >It isn't just the *.trm files. >In fact I think it is reasonable for the terminal drivers to receive >unsigned coordinates. The problem comes before that. > >Didn't we have this discussion already? > Probably did and it went right past me, sorry. >All the internal routines convert coordinates to (unsigned int). >Unfortunately sometimes they convert too soon, i.e. before clipping. >Harald Harders and I have been slowly switching the lower-level >routines over to use integer or double coordinates, and adding >proper clipping code on top of them. It should now be working >for the newer plot styles (with labels, with filledcurves between, >with vectors) but not yet for all of the older plot styles. > > > >>OK. I'm getting the feeling this is case of someone having to go >>through the pain of changing all those "unsigned" coordinate values >>inside the terminal drivers to "signed". At least I don't think it >>should wreck any working behavior. It can only make bad behavior better. >> >> >> > >It is messier than it ought to be because of the way that inverted >axis ranges are implemented. Every test for out-of-bounds has >to allow for the possibility that the axes limits are stored in >reverse order. I'm inclined to say it would be better to change that >first, and only afterwards worry about adding clipping code >everywhere. But I am not familiar with the history of the axis code, >so I don't know all the places that would be affected. > Reminds me of the image stuff. First I translated the orientation of the image (without moving data around) to just one orientation. Sometimes one can write routines with absolute values and such to get proper behavior without "getting ones footing", but often it comes out so obfuscated that it's tedious to work with at a later time. So yeah, picking an order early on is fine. (But choose notation to reflect that, for example if order doesn't matter it might be x1, x2. If it does, then perhaps xlow, xhigh.) >>If people are happy with that as a fix, I'm fine with it too. [Or it >>could be just >> >> double h = (signed) x, v = (signed) y; >> >> > >Doesn't work. It only catches the cases that are out of bounds >by virtue of having gone negative. It doesn't catch all the other >cases of improper clipping. The proper fix lies in the clipping >code, not the individual drivers. > Oh yeah, those situations where the lines go randomly off into space, often seen when zooming, right? OK, I'm content to just kludge the above on my system and fix my immediate problem. If later you want me to pick a few terminal drivers to fix up the unsigned/signed inconsistencies, let me know. Dan |
