gnuplot-beta

gnuplot not license-compatible with GPL software

[Roland S. <st...@de...>]

Hi,

while I understand that the name gnuplot is independent from the GNU
project or the FSF, I find it annoying that through a different license,
I'm not allowed to link this software with GPL programs, most
importantly, with GNU readline.

Please consider issuing gnuplot under the GPL.

Thank you very much!

Roland Stigge

Re: gnuplot not license-compatible with GPL software

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

On Thursday 29 July 2004 05:25 am, Roland Stigge wrote:
> Hi,
> 
> while I understand that the name gnuplot is independent from the GNU
> project or the FSF, I find it annoying that through a different license,
> I'm not allowed to link this software with GPL programs, most
> importantly, with GNU readline.

To the best of my knowledge, Debian is the only entity that interprets
the respective licenses in such a way as to avoid using the gnu readline
library with gnuplot.   I have argued in the past that this is a mistaken
interpretation of the GPL; nobody at that end seems to care.
Yeah, I know - I am not a lawyer.  But that doesn't mean I'm wrong :-)

In a nutshell:  
gnuplot is not a derivative work of libreadline.
The gnuplot source code does not contain any part of gnu libreadline.
gnuplot provides its own readline function, and can be used totally
independent of gnu libreadline.

The question would be moot if gnu libreadline were LGPL rather
than GPL, but that is an issue you would have to take up with them,
not with us.

In any event, Debian's refusal to package up a pre-built version
of gnuplot that links to a shared libreadline does not in any way stop you
from building your own copy linked against whatever libaries you like.
The GPL does not limit your own use of the code; it only imposes
restrictions on the conditions under which you may distribute the
result.

So download the source, configure with
	./configure --with-readline=gnu
and be happy

> Please consider issuing gnuplot under the GPL.

It is my personal opinion that the GPL is not a good license for
academic or scientific software.  My opinion matters very little,
because I am only one of many people who have contributed to
gnuplot over the years.  But if you multiply my reservations by
50 or so, to account for the larger group of contributers to the
project, you will begin to see why changing the license would
be difficult.

> Thank you very much!
> 
> Roland Stigge

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

grid outside border

[Daniel J S. <dan...@ie...>]

In Octave I've come across the a situation where the grid marks extend a 
slight bit beyond the right border.  It happens for the terminals I've 
tried--x11, postscript, png.  Attached is a PNG file.  I can't seem to 
reproduce this in gnuplot by itself, e.g., logarithm y axis, same 
margins, etc.  If this is not supposed to happen, I will add an entry to 
the SourceForge bug list.

Dan

Re: grid outside border

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

On Aug 5, 2004, at 08:51, Daniel J Sebald wrote:

> In Octave I've come across the a situation where the grid marks extend 
> a slight bit beyond the right border.  It happens for the terminals 
> I've tried--x11, postscript, png.  Attached is a PNG file.  I can't 
> seem to reproduce this in gnuplot by itself, e.g., logarithm y axis, 
> same margins, etc.  If this is not supposed to happen, I will add an 
> entry to the SourceForge bug list.

FWIW, I can't reproduce this using aquaterm as the terminal. (I guess 
that the plot was created by octave's freqz() command?)

octave 2.1.57 {gnuplot 4.0, recent CVS} and OSX 10.3.4

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: grid outside border

[Daniel J S. <dan...@ie...>]

Per Persson wrote:

>
> On Aug 5, 2004, at 08:51, Daniel J Sebald wrote:
>
>> In Octave I've come across the a situation where the grid marks 
>> extend a slight bit beyond the right border.  It happens for the 
>> terminals I've tried--x11, postscript, png.  Attached is a PNG file.  
>> I can't seem to reproduce this in gnuplot by itself, e.g., logarithm 
>> y axis, same margins, etc.  If this is not supposed to happen, I will 
>> add an entry to the SourceForge bug list.
>
>
> FWIW, I can't reproduce this using aquaterm as the terminal. (I guess 
> that the plot was created by octave's freqz() command?)
>
> octave 2.1.57 {gnuplot 4.0, recent CVS} and OSX 10.3.4


Yes.  Fairly recent CVS version.

Re: grid outside border

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

> In Octave I've come across the a situation where the grid marks extend
> a  slight bit beyond the right border.

I guess Octave has sent its "set grid" or "set tics" or "set xrange" into
gnuplot, thus it draws grid far than gnuplot defaults.Try to graw('save "lookhere.gp"'); after the plot and reload that into
fresh gnuplot.
Petr

Re: grid outside border

[Daniel J S. <dan...@ie...>]

mi...@ph... wrote:

>>In Octave I've come across the a situation where the grid marks extend
>>a  slight bit beyond the right border.
>>    
>>
>
>I guess Octave has sent its "set grid" or "set tics" or "set xrange" into
>gnuplot, thus it draws grid far than gnuplot defaults.Try to graw('save "lookhere.gp"'); after the plot and reload that into
>fresh gnuplot.
>Petr
>  
>

I've done this.  There are 134 lines in the file, all kinds of commands 
that look like default settings.  However, the only line that seems to 
apply to all the gnuplot commands associated witht the freqz.m action is a

pl '/tmp/oct-ogH8L8' t "Phase (degrees)" w lines

I know gnuplot can save only the most recent plot command, but where all 
the "set multiplot", "set lmargin", etc. went I don't know.

I'll see if I can isolate this.

Dan

Re: grid outside border

[Hans-Bernhard B. <hb...@pc...>]

On Thu, 5 Aug 2004, Daniel J Sebald wrote:

> In Octave I've come across the a situation where the grid marks extend a
> slight bit beyond the right border.

The problem is not the grid line --- it's in the right position, as you
can see by looking in the corners, where it meets the tick marks
quite nicely.

The problem is with the *border* line here.  It's in the wrong position,
by one pixel.  Normally, this would be caught automatically, because the
border lines are 2 pixels wide by default, on most terminals.

You really will have to isolate this into a stand-alone gnuplot script
to make it a worthwile target for further investigation.   I sincerely
hope octave leaves you a way of extracting the actual gnuplot commands
to a gnuplot script file (call gnuplot's "save" command, e.g.).

FC3 and odds and ends

[Daniel J S. <dan...@ie...>]

Just finished upgrading my system to Fedora Core 3.  Some observations...

Basically, gnuplot works very well.  (gnuplot 4.0 is on FC3)  CVS 
gnuplot compiles without problems.  FC3 deserves little fanfare, but I 
would say that the performance of X11 from RH7 to FC3 deserves a "wow!"  
The images have a great antialiasing effect and the speed is amazingly 
improved.  Even the polygon approximations seems to resize fairly fast.  
Very slick.


Here's an observation or two.  I notice at the command line that the 
help notice says

[sebald@localhost ~]$ gnuplot --help
Usage: gnuplot [OPTION]... [FILE]
for X11 options see 'help X11->command-line-options'

However, if one types "help X11" inside gnuplot, the subtopics do not 
get listed.  However, typing "help x11" does cause subtopics to be listed.

Also, the background of an X11 image doesn't come out as white unless I 
explicitly launch gnuplot as

[~]$ gnuplot -background white

otherwise it seems to be the default "grey" them color, which is 
slightly lighter than the "-background grey" option.  I'll investigate 
when I have time.

Dan

Re: grid outside border

[Daniel J S. <dan...@ie...>]

OK, I think I have narrowed this down.  It has to do with the xrange 
being slightly less than a whole number.  You may or may not feel this 
is gnuplot's problem or Octave should be worrying about this.  I'll just 
describe it.

Launch gnuplot with the -nofeedback option.  Then type the following set 
of commands:

set xrange [0:1.99805]
set grid
plot sin(x)
set xrange [0:2]     
replot
set xrange [0:1.99805]
replot

You should notice this behavior on the right border toggling back and 
forth.  So, yes it does seem that the border is being drawn a pixel to 
the left because of the 1.99805.  So I guess the question is whether a 
grid line should be drawn at all in this scenario.  It probably has 
something to do with rounding.

If you run gnuplot without the -nofeedback option, the feedback will 
slightly readjust the x length and the rounding will behave differently. 
 But if you move your x-window about a bit, in some locations you should 
see the right border shifted slightly to the left.  I guess what I'm 
saying is that on your particular system, if you run "gnuplot 
-nofeedback" and then

set xrange [0:1.99805]
set grid
set term png
set output 'junk.png'
plot sin(x)
set output

You should get a PNG file with the aberration.  Your X11 system may 
behave slightly different depending upon your system settings.

Unless someone wants to tackle this now, I think in the next couple days 
I'll put it in SourceForge bug list along with a couple other items 
before I forget them.

Dan

Re: grid outside border

[Daniel J S. <dan...@ie...>]

I looked into this issue of the grid line and tics to the right of the 
right border.  There is a lot of code for the tics, and I notice a 
comment in the code:

    /* FIXME HBB 20010121: keeping adding 'step' to 'tic' is
     * begging for rounding errors to strike us. */
    /* HBB 20010410: ... and strike they did :-( */

So there is probably an issue having to do with that.  Of course, one 
thing that could be done is a sanity check to make sure no tics are 
drawn if outside xleft, xright, xbot, xtop.  But those variables are not 
in the same C file....  Also, there should be a bit of code that would 
round the border up to 2.0 if [0:1.99805].  What I mean, is that the 
range should probably be rounded to the nearest, oh, 1/2% of the length. 
 That is, when it comes to the final computation of the range, treat 
1.99805 as follows

xmax - xmin = 1.99805

(xmax - xmin)*0.005 = 0.0099903

which means we should round to the nearest 0.01, i.e. 1.99805 rounds to 
2.0.  It is a little bit difficult to imagine an elegant algorithm to do 
this, but it may involve working with the exponents of floats in 
exponential notation.  (Can't think of any C constructs to do that.)  Or 
perhaps working with logarithms.

Not proposing this be done, but I hope you catch my drift.

Dan