Re: crash bug in pdf terminal

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

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.