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

Patch for RFE [ 992352 ] [Win32] console backlog length is hardwired

[Bastian M. <bma...@we...>]

Hi,

this patch adds two new settings to wgnuplot.ini:
`BacklogLength` and `BacklogWidth`. This way a user can
adjust the length and width of the internal backlog
buffers accordings to his personal preferences.

Bastian

--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg
Philosophenweg 12
69120 Heidelberg

Re: bug in terminals affected by 'set size'

[Robert H. <en...@no...>]

On Tue, 4 Oct 2005, Ethan Merritt wrote:

> Because "1 x 1" means "the full plotting area".
> By definition, if you plot outside that area then you are asking for
> trouble.

In many cases though, it means "the default plotting area". For example
the epslatex terminal now has a default of "5 x 3.5 inches". It is quite
conceivable to need an epslatex plot that is larger than this.

> Could someone explain to me what is the actual use intended for one
> of these larger-than-full-page plots?  Is the idea to make a 
> posterboard-sized plot using PostScript?  But in that case you 
> probably *do* want to scale up the line widths and fonts, so that
> they remain readable at normal poster-viewing distance.

Again, using the epslatex terminal as an example: The default size is
based on a typical page width, and a reasonable aspext ratio. Personally I
prefer a slightly taller plot, (because I tend to put the key below) and
my page width isn't exactly 5 inches, so I have:

set size (345.0/72.27)/5.0, 4.0/3.5;

in all my gnuplot files. Secondly however when I use multiplot, I often
want two plots one above the other but keeping the total width to be the
page width, so you then need a:

set size 1,2;

This seems perfectly reasonable, and as far as I can tell works.
Basically your argument only makes sense if each terminal allows an
explicit size argument in the term options. Then the "set size" option
simply allows you to scale the plot within those bounds.

-- 
            ___    ____    ____
     ______/   \__//   \__/____\       Robert Hart
   _/   \_/  :           //____\\      15 Benington Drive
  /|      :  :  ..      /        \     Wollaton
 | |     ::     ::      \        /     Nottingham
 | |     :|     ||     \ \______/      NG8 2TF
 | |  _  ||     ||  __  |\  /  |
  \|     ||     ||      |   / | \      en...@no...
   | ___ || ___ || ____ |  / /_\ \
   |  _  ||  _  ||  __  | /  /    \    http://www.nott.ac.uk/~enxrah
    \___/  \___/ |      |/__/      \
                 _\____/    \      /
                /____             /
               /     \           /
               \______\_________/


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: bug in terminals affected by 'set size'

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

I wrote
| I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
| isn't 'set size 2,2' the only way to get a postscript file twice as large
| as the default size?

Ethan Merritt replied:
> What exactly do you mean by "twice as large"?

I thought I stated above, "twice as large as the default size".

> The default postscript output fills a US Letter page.

Not for eps.  In particular, using
         G N U P L O T
         Version 4.0 patchlevel 0
         last modified Thu Apr 15 14:44:22 CEST 2004
         System: Linux 2.4.31
I just tried the commands
   set term postscript eps
   set output '/tmp/sin.ps'
   plot sin(x)
   set output
and sent the resulting file to an (A4) laser printer.  The resulting
plot is 12 x 8.6 cm.


> I can understand griping about not having an A4 option,
> but are you really trying to print something to a
> 15" x 22" piece of paper?

Well, I have certainly printed things on A3 paper (= roughly US 11x17),
and A3 laser printers are not uncommon.

A0 printers (= poster-sized, 91.5 x 119cm) are rather less common,
but I have used gnuplot figures in several such posters in the past,
and plan to do so again in the future...


>
> Note that if you do say
> 	set size 2,2
> 	set term post
> It produces an output file containing the lines
> %%BoundingBox: -454 50 554 1490
> %%Orientation: Landscape
>
> While this is legal PostScript, it is unlikely to print
> correctly on a real output device since the x coordinate
> go negative.
>
> In general I would say the better choice is to select eps
> output, and then scale the resulting eps figure to whatever
> size you like in the final document.  But perhaps I am
> misunderstanding the intended use.

I often do this... but due to issues like fonts and linewidths, I'd
also like to be able to arbitrarily set the natural size of the eps
figure... including sometimes set it to a size larger than the gnuplot
default.

ciao,

-- 
-- Jonathan Thornburg <jt...@ae...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam

Re: pslatex terminal output--Problem identified.

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

On Tuesday 04 October 2005 03:35 pm, John W. Eaton wrote:
> On  4-Oct-2005, Petr Mikulik wrote:
> 
> | > Another thing that would be very useful would be a way to query
> | > individual settings.  Parsing text output would be OK, provided that
> | > it is easy to do that (i.e., the output is structured in some way, not
> | > some natural language thing) and the format does not change.

Would it be preferable if gnuplot's "show <foo>" command produced output
corresponding to the input syntax, just as "save" does now?

For example, for "show title"

current output:
    title is "Foo", offset at ((character units) 0, 0, 0)
equivalent line in "save" corresponds in input syntax:
    set title "Foo"  offset character 0, 0, 0 font "" norotate

>> Do you mean  gget.m  from octave-forge?
>>
> it is a terrible kluge and has a built-in race condition because
> it sends a "save" command to gnuplot then waits a while (how long is
> long enough?) and then parses the output.

Can it not read back synchronously?

	fprintf(GNUPLOT_OUT,"save '| outpipe'\n");
	fflush(GNUPLOT_OUT);
	while ( fgets(&line, sizeof(line), GNUPLOT_INPIPE) )
	    look_for_desired_option(&line);
		


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

Re: bug in terminals affected by 'set size'

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

On Tuesday 04 October 2005 01:12 pm, Harald Harders wrote:
> 
> And I do not see a reason why gnuplot shall not be able to generate plots
> with a size larger than 1 x 1. 

Because "1 x 1" means "the full plotting area".
By definition, if you plot outside that area then you are asking for
trouble.

> If it is valid to reduce the size of a plot 
> by using 'set size' before 'set terminal' (which has been agreed in a
> former discussion where I complained about cropped arrows in splots larger
> than 1 x 1), an increase of the size to a measure larger than 1 x 1 should
> also be possible.

No.  See above.  It makes perfect sense to ask for the current plot
to fill only 1/4 of the plotting area.  That's the normal use of
multiplot mode.  You are making, say, 4 plots on the same page, and
each one should occupy 1/4 of the area. Asking to fill *more* than the
plotting area makes no sense and should not be allowed IMHO.

> I still do not understand the arguments why a plot larger than 1 x 1
> should not be used. It seems ignorant to me. The bug also does not apply
> to pixel based plots if you want to have the same font sizes and
> linewidths in two different plots with a different size.

I do not follow which side of the argument you are pursuing in these
sentences.

Are you proposing that we change the meaning of "size" for pixel-based
terminals, so that in the future it would mean "use this as a multiplier
for # of pixels, all font sizes, line widths, point sizes, etc"?
That would make some sense, since it would effectively be changing the
resolution of the output image. But it would be a major change from the
way things work now.  It also does exactly the opposite of what you
said you wanted PostScript output to do in the case of scaling up the
output size.

Could someone explain to me what is the actual use intended for one
of these larger-than-full-page plots?  Is the idea to make a 
posterboard-sized plot using PostScript?  But in that case you 
probably *do* want to scale up the line widths and fonts, so that
they remain readable at normal poster-viewing distance.


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

Re: pslatex terminal output--Problem identified.

[John W. E. <jw...@be...>]

On  4-Oct-2005, Petr Mikulik wrote:

| > Another thing that would be very useful would be a way to query
| > individual settings.  Parsing text output would be OK, provided that
| > it is easy to do that (i.e., the output is structured in some way, not
| > some natural language thing) and the format does not change.
| 
| Do you mean  gget.m  from octave-forge?
| It works OK.

No, it is a terrible kluge and has a built-in race condition because
it sends a "save" command to gnuplot then waits a while (how long is
long enough?) and then parses the output.  The parsing step seems a
bit dicey to me, since as far as I know, the format of the output is
not well defined and could change with any new release of gnuplot.

jwe

Re: pslatex terminal output--Problem identified.

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

> I can't seem to reproduce the problem with a recent CVS version so
> that's good.

The (e)pslatex drivers have been completely rewritten for 4.1.

> But the problem with sticky terminal options remains.  For
> non-interactive use by programs like Octave, it would be very helpful
> if there were some way to push and pop all settings, not just some of
> them.  That way, the application that is driving gnuplot does not have
> to keep track of the complete history of all option settings when
> making a temporary change.

That would require the previously proposed "unset termoptions".

> Another thing that would be very useful would be a way to query
> individual settings.  Parsing text output would be OK, provided that
> it is easy to do that (i.e., the output is structured in some way, not
> some natural language thing) and the format does not change.

Do you mean  gget.m  from octave-forge?
It works OK.

---
PM

Re: bug in terminals affected by 'set size'

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

On Tuesday 04 October 2005 12:54 pm, Don Taber wrote:
> > > Various terminals the size of whose output can be changed with
> > > 'set size' have a bug in current cvs.  When the size is increased
> > > by setting the size with factors greater than one, 
> > 
> > So don't do that.
> > 
> 
> It's not that easy for several reasons.
> 
> 1. This resizing technique *used* to work and there are scripts out there
> (some of which are mine) that rely on it.

Several of gnuplot's terminal drivers have been entirely replaced
or re-written, for good reason.  I can believe that the old (5 years+)
png driver used to behave differently, but it's now dead and buried.


> 2. For 'set term pbm' there is no size argument and a subsequent
> 'set size' command is the only way to change the size.  Try
> 'help set term pbm' and you will find that you are advised to
> use size > 1. 

OK. So let's fix the pbm terminal. That sounds easy.

> 3. For other terminals, the documentation specifically states
> that the size may be changed with 'set size'.  No warning that
> size > 1 won't work.  

That also can be fixed.

> And it still *does* work for the plots.   
> It is only reasonable that it should work for the labels too.

I can assure you that it does not work reliably (in the sense
of working for all terminals) for the plots either.

> I did not try to fix this myself because I am not sufficiently
> familiar with the terminal driver code.  But my suspicion
> is that it would be easier to restore the previous behavior
> than to fix all the documentation to reflect the new behavior.

No. It is not fixable in either png or pdf drivers, since it is
the underlying library rather than any gnuplot code that causes
a problem.  pdflib in particular is ridiculously prone to segfaults
if you try to draw or write outside of the pre-defined plot
boundaries.  I have not looked in detail at other drivers, but 
I think it's only luck that size>1 ever worked.

My [one] vote would be to fix the terminal drivers that have no
separate size option, and then limit the global size parameter
to the range 0<size<1.


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

Re: bug in terminals affected by 'set size'

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

On Tue, 4 Oct 2005, Ethan Merritt wrote:

> On Tuesday 04 October 2005 10:03 am, Jonathan Thornburg wrote:
> >
> > I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
> > isn't 'set size 2,2' the only way to get a postscript file twice as large
> > as the default size?
>
> What exactly do you mean by "twice as large"?

[...]

> In general I would say the better choice is to select eps
> output, and then scale the resulting eps figure to whatever
> size you like in the final document.  But perhaps I am
> misunderstanding the intended use.

Definitely not. If you want to have consistent plots in a document, you
really should use the same linewidth and the same font size. Thus, all
plots in a document should be scaled by the same amount while of course
not scaling is most elegant. For example \includegraphics{figure} is more
elegant than \includegraphics[scale=2]{figure}.

And I do not see a reason why gnuplot shall not be able to generate plots
with a size larger than 1 x 1. If it is valid to reduce the size of a plot
by using 'set size' before 'set terminal' (which has been agreed in a
former discussion where I complained about cropped arrows in splots larger
than 1 x 1), an increase of the size to a measure larger than 1 x 1 should
also be possible. For the arrow bug, I have a patch that still seems to
work for me (I haven't tested it since a long time), patch #1104264. But
for the bug concerning the labels, I also do not have a solution.

I still do not understand the arguments why a plot larger than 1 x 1
should not be used. It seems ignorant to me. The bug also does not apply
to pixel based plots if you want to have the same font sizes and
linewidths in two different plots with a different size.

It should be easy to adapt my patch also to labels.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: bug in terminals affected by 'set size'

[Don T. <dt...@to...>]

> > Various terminals the size of whose output can be changed with
> > 'set size' have a bug in current cvs.  When the size is increased
> > by setting the size with factors greater than one, 
> 
> So don't do that.
> 

It's not that easy for several reasons.

1. This resizing technique *used* to work and there are scripts out there
(some of which are mine) that rely on it.

2. For 'set term pbm' there is no size argument and a subsequent
'set size' command is the only way to change the size.  Try
'help set term pbm' and you will find that you are advised to
use size > 1. 

3. For other terminals, the documentation specifically states
that the size may be changed with 'set size'.  No warning that
size > 1 won't work.  And it still *does* work for the plots.  
It is only reasonable that it should work for the labels too.


I did not try to fix this myself because I am not sufficiently
familiar with the terminal driver code.  But my suspicion
is that it would be easier to restore the previous behavior
than to fix all the documentation to reflect the new behavior.

Don Taber

Re: Close Mac installation bug reports?

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

On Tuesday 04 October 2005 05:59 am, Per Persson wrote:
> 
> > 1059955  	  no pdf term on Mac?
> 
> What happened to the "build help only for built drivers" issue?

I'm not entirely sure.
But there is a separate bug open for exactly that issue, which
doesn't really have anything to do with pdf or Mac in particular.

Bug  #963176  	  only create docs for available terminals


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

Re: bug in terminals affected by 'set size'

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

On Tuesday 04 October 2005 10:03 am, Jonathan Thornburg wrote:
> 
> I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
> isn't 'set size 2,2' the only way to get a postscript file twice as large
> as the default size?

What exactly do you mean by "twice as large"?
The default postscript output fills a US Letter page.
I can understand griping about not having an A4 option,
but are you really trying to print something to a
15" x 22" piece of paper?

Note that if you do say
	set size 2,2
	set term post
It produces an output file containing the lines
%%BoundingBox: -454 50 554 1490
%%Orientation: Landscape

While this is legal PostScript, it is unlikely to print
correctly on a real output device since the x coordinate
go negative.

In general I would say the better choice is to select eps
output, and then scale the resulting eps figure to whatever
size you like in the final document.  But perhaps I am
misunderstanding the intended use.



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

Re: bug in terminals affected by 'set size'

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

On Tue, 4 Oct 2005, Ethan Merritt wrote:
[[set size to a value > 1]]
> So don't do that.
>
> Neither the png/jpeg/gif terminal driver nor the pdf terminal
> driver can do anything useful with size>1.  You are basically
> telling it to draw outside of the legal drawing area.
> Other terminals may also belong on that list.
>
> Basically, size should never be > 1, although some terminal
> types may handle this case more gracefully than others.

I'm not disagreeing with Ethan for bitmap terminals, but for postscript,
isn't 'set size 2,2' the only way to get a postscript file twice as large
as the default size?

ciao,

-- 
-- Jonathan Thornburg <jt...@ae...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam

Re: bug in terminals affected by 'set size'

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

On Tuesday 04 October 2005 09:19 am, Don Taber wrote:
> Various terminals the size of whose output can be changed with
> 'set size' have a bug in current cvs.  When the size is increased
> by setting the size with factors greater than one, 

So don't do that.

Neither the png/jpeg/gif terminal driver nor the pdf terminal
driver can do anything useful with size>1.  You are basically
telling it to draw outside of the legal drawing area.  
Other terminals may also belong on that list.

Basically, size should never be > 1, although some terminal
types may handle this case more gracefully than others.

In the case of the png terminal, you should define the
image size directly and leave "size" equal to 1.

	set term png size 1234, 2345






> any labels outside 
> the original size (from 'set terminal xxx size n,m') do not
> appear.  The happens in png, jpeg, gif and pbm (and perhaps others
> I don't know about.)  A demo script follows.  In the 'bad' output
> the title, key labels, and half the [xy]tic labels are missing.
> 
> set term png
> set output 'good.png'
> plot sin(x), cos(x)
> set size 1.5, 1.5
> set output 'bad.png'
> replot
> 
> Don Taber
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.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

bug in terminals affected by 'set size'

[Don T. <dt...@to...>]

Various terminals the size of whose output can be changed with
'set size' have a bug in current cvs.  When the size is increased
by setting the size with factors greater than one, any labels outside
the original size (from 'set terminal xxx size n,m') do not
appear.  The happens in png, jpeg, gif and pbm (and perhaps others
I don't know about.)  A demo script follows.  In the 'bad' output
the title, key labels, and half the [xy]tic labels are missing.

set term png
set output 'good.png'
plot sin(x), cos(x)
set size 1.5, 1.5
set output 'bad.png'
replot

Don Taber

Re: pslatex terminal output--Problem identified.

[John W. E. <jw...@be...>]

On  2-Oct-2005, Ethan A Merritt wrote:

| On Sunday 02 October 2005 12:02 pm, Dmitri A. Sergatskov wrote:
| > One example is when one does "set term post eps" and later
| > "set term pslatex". Since the "eps" option is sticky it messes up the
| > pslatex terminal...
| 
| Are you sure?  That would indeed be a bug.
| But it doesn't seem to be the case here when I try it.
| I get identical output from the pslatex terminal whether or not
| a previous plot has used "set term post eps".  If you can
| reproduce your problem, please send a bug report and a script
| that demonstrates the problem.
| 
| gnuplot> set term post eps
| Terminal type set to 'postscript'
| Options are 'eps noenhanced defaultplex \
|    leveldefault monochrome colortext \
|    dashed dashlength 1.0 linewidth 1.0 butt \
|    palfuncparam 2000,0.003 \
|    "Helvetica" 14 '
| gnuplot> set term pslatex
| Terminal type set to 'pslatex'
| Options are 'rotate   leveldefault monochrome colortext \
|    dashed dashlength 1.0 linewidth 1.0 butt \
|    palfuncparam 2000,0.003 \
|    rotate noauxfile '

Try

  plot sin(x) title "line 1"
  set term postscript eps enhanced color solid
  set output "foo.eps"
  replot
  set term pslatex
  set output "foo.tex"
  replot
  quit

With gnuplot 4.0 patchlevel 0, then include the resulting foo.tex file
in a simple document like

  \documentclass{article}
  \usepackage{graphicx}
  \begin{document}
  \input{foo}
  \end{document}

and process with latex and dvips.  The final output has the axes and
labels (the stuff in the TeX part of the figure) correctly rendered,
but the PS part is 1/4 the proper size, and displayed in the lower
left corner of the TeX part.

I can't seem to reproduce the problem with a recent CVS version so
that's good.

But the problem with sticky terminal options remains.  For
non-interactive use by programs like Octave, it would be very helpful
if there were some way to push and pop all settings, not just some of
them.  That way, the application that is driving gnuplot does not have
to keep track of the complete history of all option settings when
making a temporary change.

Another thing that would be very useful would be a way to query
individual settings.  Parsing text output would be OK, provided that
it is easy to do that (i.e., the output is structured in some way, not
some natural language thing) and the format does not change.

jwe

Re: Close Mac installation bug reports?

[Per P. <per...@ma...>]

 
On Monday, October 03, 2005, at 07:09PM, Ethan Merritt <merritt@u.washington.edu> wrote:

>Can we close out the following bug reports?
>
> 1233099  	  mac installer fails with "nothing to install"
> 1283885  	  can't install gnuplot

Both closed now.

> 1059955  	  no pdf term on Mac?

What happened to the "build help only for built drivers" issue?

/Per

Re: plot perspective

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

William Estrada asked:
>  How can I make gnuplot produce a 3D plot with true prespective.  By
> that I mean that X, Y and Z
> all relate to each other.  The scale of X, Y and Z are the same.

Juergen Wieferink replied
|     I am not sure what you mean. If you simply want to change the aspect
| ratio of the plot, you should have a look at the "help size"
| documentation page.

I think William Estrada's question may be the same as a gnuplot
problem I've struggled with for years; maybe explaining my problem
will help this discussion...

Basically, I want the 'splot' equivalent of 'set size ratio -1'.
That is, suppose I have a bunch of data points on the surface of a
sphere.  I'd like to use 'splot' to produce a view of them where the
sphere looks spherical, not ellipsoidal.


For a demonstration, fetch the files

    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.0
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.1
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.2
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.3
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.4
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/data.5

and try the following gnuplot commands:

   set hidden3d nooffset
   unset key
   splot 'data.0' with lines linetype 1,   \
         'data.1' with lines linetype 2,   \
         'data.2' with lines linetype 3,   \
         'data.3' with lines linetype 4,   \
         'data.4' with lines linetype 5,   \
         'data.5' with lines linetype 6

(This is adapted from a conference talk I gave a couple of days ago.)
This should show a set of 6 patches covering a sphere.  As is, it shows
a rather squashed ellipsoid.

I think this is the same problem that William Estrada described, no?


The current workaround is to manually 'set size', with size parameters
obtained by trial and error (and measuring the resulting plots with a ruler).
As well as being very clumsy, the necessary 'set size' parameters also
differ from one terminal to another.

What's worse, it's almost impossible to determine the right parameters
if the data to be plotted aren't intrinsically spherical.  For example,
take a look at
    http://www.aei.mpg.de/~jthorn/spool/gnuplot-3d-demo/ahs.t=5.eps
(This was a figure in a published paper of mine about 2 years ago.)
This used the parameters
   set view 70, 20
   set size 0.75, 1.70
but I had to eyeball these -- there was no practical way to determine
the "correct" parameters.

ciao,

-- 
-- Jonathan Thornburg <jt...@ae...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam

Re: cannot build with png support in gnuplot 4.1

[<as...@gm...>]

Hi, I had exactly the same problem. To fix it, i had to install packages
png-devel and jpeg-devel (I was building gnuplot on SuSE 9.1). After that,
I'd recompiled gnuplot and everything works fine.

Hern=E1n



--
------------------------------------------------
Lic. Hern=E1n Gonzalo Asorey
Instituto Balseiro - U. Nac. Cuyo
Av. Exequiel Bustillo N=B0 9500
(8400) San Carlos de Bariloche
Pcia. de R=EDo Negro - Argentina
---------------------------------------------
as...@ib...
On 10/3/05, Ethan Merritt <merritt@u.washington.edu> wrote:
>
> On Monday 03 October 2005 01:24 pm, Matt Fischer wrote:
> > Just grabbed the latest from CVS (10/3) and I cannot build with png
> support.
> > Configure shows that it should be working:
> >
> > checking for png_create_write_struct in -lpng... yes
> > checking png.h usability... yes
> > checking png.h presence... yes
> > checking for png.h... yes
> > ...
> > ** Configuration summary for gnuplot 4.1.0:
> > ...
> > Enable generation of PNG files
> > However, when I build, I dont get png support
>
>
> 4.1 does not have a separate PNG driver, it has a unified
> PNG/JPEG/GIF driver built on top of the GD library
> (libgd). The output you show above means that gnuplot's
> build process found various pieces of a PNG installation
> on your machine, but they do not say anything about
> whether it found the rest of libgd.
>
> Please check that you have libgd installed, and then try again.
> You can get the latest version of libgd from
> http://www.boutell.com/gd/
>
>
> --
> Ethan A Merritt merritt@u.washington.edu
> Biomolecular Structure Center
> Mailstop 357742
> University of Washington, Seattle, WA 98195
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: cannot build with png support in gnuplot 4.1

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

On Monday 03 October 2005 01:24 pm, Matt Fischer wrote:
> Just grabbed the latest from CVS (10/3) and I cannot build with png support.
> Configure shows that it should be working:
> 
> checking for png_create_write_struct in -lpng... yes
> checking png.h usability... yes
> checking png.h presence... yes
> checking for png.h... yes
> ...
> ** Configuration summary for gnuplot 4.1.0:
> ...
> Enable generation of PNG files
> However, when I build, I dont get png support


4.1 does not have a separate PNG driver, it has a unified
PNG/JPEG/GIF driver built on top of the GD library
(libgd).  The output you show above means that gnuplot's
build process found various pieces of a PNG installation
on your machine, but they do not say anything about 
whether it found the rest of libgd.

Please check that you have libgd installed, and then try again.
You can get the latest version of libgd from
	http://www.boutell.com/gd/


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

Re: cannot build with png support in gnuplot 4.1

[Matt F. <tad...@gm...>]

I'm not that dumb :) Any other ideas?

mfischpc <03:20:25> ~/gnuplot/src>./gnuplot

G N U P L O T
Version 4.1 patchlevel 0
last modified Sat Jul 3 00:04:32 CEST 2004
System: Linux 2.6.10-5-386

Copyright (C) 1986 - 1993, 1998, 2004
Thomas Williams, Colin Kelley and many others

Type `help` to access the on-line reference manual.
The gnuplot FAQ is available from
http://www.gnuplot.info/faq/

Send comments and requests for help to
<gnu...@li...>
Send bugs, suggestions and mods to
<gnu...@li...>


Terminal type set to 'unknown'
gnuplot> set terminal png
^
unknown or ambiguous terminal type; type just 'set terminal' for a list

On 10/3/05, Petr Mikulik <mi...@ph...> wrote:
>
> > However, when I build, I dont get png support
> >
> > gnuplot> set terminal png
> > ^
> > unknown or ambiguous terminal type; type just 'set terminal' for a list
> >
> > Is there an issue with png support in CVS or any other ideas I could
> try?
>
> =3D> build works, running not =3D> you probably run another binary of gnu=
plot
> (/usr/bin/gnuplot vs .../local/...).
>
> ---
> PM
>



--
---------------------------------------------------------------------
Cuz you know the phrase, "Once again its on".
-- Tadowguy --
---------------------------------------------------------------------

Re: cannot build with png support in gnuplot 4.1

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

> However, when I build, I dont get png support
>
> gnuplot> set terminal png
> ^
> unknown or ambiguous terminal type; type just 'set terminal' for a list
>
> Is there an issue with png support in CVS or any other ideas I could try?

=> build works, running not => you probably run another binary of gnuplot
(/usr/bin/gnuplot vs .../local/...).

---
PM

cannot build with png support in gnuplot 4.1

[Matt F. <tad...@gm...>]

Just grabbed the latest from CVS (10/3) and I cannot build with png support=
.
Configure shows that it should be working:

checking for png_create_write_struct in -lpng... yes
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
...
** Configuration summary for gnuplot 4.1.0:
...
Enable generation of PNG files


However, when I build, I dont get png support

gnuplot> set terminal png
^
unknown or ambiguous terminal type; type just 'set terminal' for a list

Is there an issue with png support in CVS or any other ideas I could try?

--
---------------------------------------------------------------------
Cuz you know the phrase, "Once again its on".
-- Tadowguy --
---------------------------------------------------------------------

Close Mac installation bug reports?

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

Can we close out the following bug reports?

 1233099  	  mac installer fails with "nothing to install"
 1283885  	  can't install gnuplot
 1059955  	  no pdf term on Mac?

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

Re: GNUPlot frontends page (addition)

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

> Please consider my program PlotDrop for inclusion in the list of GNUPlot
> frontends.  Information about it is below.
> http://icculus.org/~jcspray/plotdrop/

Put into the "Links" section.

Please note the name "gnuplot" not "GNUPlot" or anything else.

Ad PlotDrop: it would be useful to re-use the plotting window instead of 
launching a new one.

---
PM