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

Re: exposing cairo context from gnuplot

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

On Monday 07 September 2009, Richard Henwood wrote:
> Hi All,
> 
> I've been using Cairo (cairographics.org) a fair bit recently. I have
> not found a plotting library which is as mature as gnuplot.
> 
> I understand that the wxWidgets terminal uses cairo.
> 
> Has anyone considered the possibility of exposing the cairo context from
> within gnuplot/wxWidgets to the outside world?

The development version has two new drivers - pngcairo and pdfcairo,
the use the cairo library.  Not sure if that's what you meant.
Both drivers will be in the version 4.4 release candidate, which I
hope we can put out soonish.

exposing cairo context from gnuplot

[Richard H. <ric...@st...>]

Hi All,

I've been using Cairo (cairographics.org) a fair bit recently. I have
not found a plotting library which is as mature as gnuplot.

I understand that the wxWidgets terminal uses cairo.

Has anyone considered the possibility of exposing the cairo context from
within gnuplot/wxWidgets to the outside world?

best regards,
Richard
-- 
Scanned by iCritical.

Re: launch help in pdf or on web

[Tatsuro M. <tma...@ya...>]

Hello

http://www.geocities.jp/tmgpltwin/Files/Files.html
0022 gnuplot.chm.zip, 376,810 bytes, 2009-09-07, zipped gnuplot.chm file generated by HTML Help
Complier

The above file was made by mere translattion of htmldocs of the recent cvs sources.
That is a mere test of HTML Help Complier.

In the HTML help complier has ability to transtale *.hpj to *.hhp (HTML Help Project file).
However it could not be used.

Regards

Tatsuro
 

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> --- Petr Mikulik wrote:
> 
> > Or shell we ship the CHM 
> > help file (is there an appropriate convertor for gnuplot formats? I've 
> > googled one shareware hlp2chm.exe.)?
> 
> I have tried to convert the html-style gnuplot documents to a chm file by HTML Help Workshop.
> However customization of html files to chm help for index or so will be recommended.
> 
> Now html documents in 'make' are produced by latex2html.
> 
> I think that it is better to convert doc2rtf for Help Workshop to program like doc2html for HTML
> Help
> Workshop.
> 
> I have tried the above. However, my limited ability and time prevents me to go ahead :-( .
> 
> Regards
> 
> Tatsuro
>    

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: launch help in pdf or on web

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik wrote:

> Or shell we ship the CHM 
> help file (is there an appropriate convertor for gnuplot formats? I've 
> googled one shareware hlp2chm.exe.)?

I have tried to convert the html-style gnuplot documents to a chm file by HTML Help Workshop.
However customization of html files to chm help for index or so will be recommended.

Now html documents in 'make' are produced by latex2html.

I think that it is better to convert doc2rtf for Help Workshop to program like doc2html for HTML Help
Workshop.

I have tried the above. However, my limited ability and time prevents me to go ahead :-( .

Regards

Tatsuro
   

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: CVS version: Black background default for PNG

[Philipp K. J. <ja...@ie...>]

On Sunday 06 September 2009 02:54:34 pm Ethan Merritt wrote:
> On Sunday 06 September 2009, Philipp K. Janert wrote:
> > Apologies.
> >
> > I simply used:
> > 	set terminal png
> > which I assume means the GD terminal.
>
> Not necessarily, but in your case - yes, since you are linked against
> libgd.
>
> > There have been no changes to my gnuplot
> > config scripts, that would explain the observed
> > change in behavior.
> >
> > Here is the output from ldd (slightly trimmed):
> >         libgd.so.2 => /usr/lib64/libgd.so.2 (0x00007fd16cf65000)
>
> Unfortunately, that is non-informative.
> Could you please look in wherever-it-is/gd.h to see what the actual
> version is?  2.0.35 is common, 2.0.36 is bleeding edge.

#define GD_VERSION_STRING "2.0.36"

But I have seen different behavior (white default bg)
before with this same GD lib. I have not updated my
Linux install in a year, but have rebuilt gnuplot from
CVS several times since then. 

> >
> > In other words, I see the black background only
> > for non-transparent backgrounds.
>
> Email me one of these png images so that I can see what it claims to be.

Will follow outside the mailing list.

Re: CVS version: Black background default for PNG

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

On Sunday 06 September 2009, Philipp K. Janert wrote:
> 
> Apologies. 
> 
> I simply used:
> 	set terminal png
> which I assume means the GD terminal.

Not necessarily, but in your case - yes, since you are linked against libgd.

> There have been no changes to my gnuplot
> config scripts, that would explain the observed
> change in behavior.
> 
> Here is the output from ldd (slightly trimmed):
>         libgd.so.2 => /usr/lib64/libgd.so.2 (0x00007fd16cf65000)

Unfortunately, that is non-informative.
Could you please look in wherever-it-is/gd.h to see what the actual
version is?  2.0.35 is common, 2.0.36 is bleeding edge.  

> >
> > The only related thing that comes to mind is that if you create
> > a transparent png image, the nominal background (which you don't
> > actually see because it's transparent :-) is black.
> > That is necessary in order to get smooth alpha-blending.
> 
> I don't think this is it. I have tried it when setting 
> 	set t png notransparent
> explicitly and the result is black background, but
> when I say
> 	set t png transparent
> the background is not black, but the typical 
> checkerboard that my image viewer uses for
> transparent images.
> 
> In other words, I see the black background only
> for non-transparent backgrounds.

Email me one of these png images so that I can see what it claims to be.

	thanks,

		Ethan

Re: CVS version: Black background default for PNG

[Philipp K. J. <ja...@ie...>]

Apologies. 

I simply used:
	set terminal png
which I assume means the GD terminal.

There have been no changes to my gnuplot
config scripts, that would explain the observed
change in behavior.

Here is the output from ldd (slightly trimmed):
        libgd.so.2 => /usr/lib64/libgd.so.2 (0x00007fd16cf65000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fd16cd41000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fd16cabb000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fd16c893000)
 (0x00007fd16a9c4000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 
(0x00007fd16a7b8000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007fd16a56e000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007fd16a2f3000)
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 
(0x00007fd16a0ae000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 
(0x00007fd169eaa000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fd169be5000)
        libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 
(0x00007fd169602000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 
(0x00007fd169362000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 
(0x00007fd168c9e000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 
(0x00007fd168a83000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 
(0x00007fd168851000)
 
>
> The only related thing that comes to mind is that if you create
> a transparent png image, the nominal background (which you don't
> actually see because it's transparent :-) is black.
> That is necessary in order to get smooth alpha-blending.

I don't think this is it. I have tried it when setting 
	set t png notransparent
explicitly and the result is black background, but
when I say
	set t png transparent
the background is not black, but the typical 
checkerboard that my image viewer uses for
transparent images.

In other words, I see the black background only
for non-transparent backgrounds.

>
> 	Ethan
>
> > This seems to occur only for PNG, but not for the GIF
> > or JPG terminals
> >
> > I am not sure when this first occurred - the current
> > CVS version behaves the way as just described, but
> > the did not do so a few months ago.
> >
> > I think it would be desirable to have white again be the
> > background for the PNG terminal (consistent with the
> > other terminals).
> >
> > Best,
> >
> > 		Ph.
> >
> >
> > -------------------------------------------------------------------------
> >----- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> > 30-Day trial. Simplify your report design, integration and deployment -
> > and focus on what you do best, core application coding. Discover what's
> > new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: CVS version: Black background default for PNG

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

On Sunday 06 September 2009, Philipp K. Janert wrote:
> 
> The current CVS version seems to make black the 
> default background color for the PNG terminal. This
> seems to be new behavior

I don't see any such behaviour here.
Please clarify whether this is the libgd png terminal, or the cairo png
terminal.  In either case please also tell us the specific version of
libgd or cairo that gnuplot is linked against.

Also please tell us the precise options of your command
 "set term png ...."


The only related thing that comes to mind is that if you create
a transparent png image, the nominal background (which you don't
actually see because it's transparent :-) is black.  
That is necessary in order to get smooth alpha-blending.

	Ethan

> This seems to occur only for PNG, but not for the GIF
> or JPG terminals
> 
> I am not sure when this first occurred - the current 
> CVS version behaves the way as just described, but
> the did not do so a few months ago.
> 
> I think it would be desirable to have white again be the
> background for the PNG terminal (consistent with the
> other terminals).
> 
> Best,
> 
> 		Ph.
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

CVS version: Black background default for PNG

[Philipp K. J. <ja...@ie...>]

The current CVS version seems to make black the 
default background color for the PNG terminal. This
seems to be new behavior - the default used to be
white.

This seems to occur only for PNG, but not for the GIF
or JPG terminals.

I am not sure when this first occurred - the current 
CVS version behaves the way as just described, but
the did not do so a few months ago.

I think it would be desirable to have white again be the
background for the PNG terminal (consistent with the
other terminals).

Best,

		Ph.

Re: Possible fix for Windows bug #2213362

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

On Sunday 06 September 2009, Tatsuro MATSUOKA wrote:
> Hello Ethan Merritt 
> 
> I have tested your patch.
> 
> The results are fine.

Thanks!

	Ethan



> Please see
> http://www.geocities.co.jp/tmgpltwin/Files/Files.html
> 
> 0021 2213362.pdf,22,378 bytes, 2009-09-06, Results for the patch for the bug ( 2213362 win.trm: Extra
> line from end of graph to key sample) by Ethan Merritt (
> http://www.nabble.com/Possible-fix-for-Windows-bug--2213362-td25314642.html)
> 
> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt  wrote:
> 
> > The win terminal Bug
> > 
> >  2213362  	 win.trm: Extra line from end of graph to key sample
> > 
> > has been with us since 4.2.4.  I really want to get this fixed before
> > putting out a 4.4-rc1.
> > 
> > Could somebody with a Windows build system please test whether the 
> > attachd patch cures it?
> > 
> > In a nutshell, if a line plot connects exactly 199 points (polymax - 1)
> > then an extra line is drawn.   Simple test case:
> > 
> > set term win
> > set key left
> > set samples 199
> > plot x
> > 
> > 		thanks in advance for any assistance,
> > 
> > 				Ethan
> > > diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> > --- gnuplot/src/win/wgraph.c	2009-08-29 14:42:00.000000000 -0700
> > +++ gnuplot-cvs/src/win/wgraph.c	2009-09-05 20:57:28.000000000 -0700
> > @@ -917,6 +917,7 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
> >  	    polyi++;
> >  	    if (polyi >= polymax) {
> >  		Polyline(hdc, ppt, polyi);
> > +		MoveTo(hdc, xdash, ydash);     /* EAM 5 Sept 2009 */
> >  		ppt[0].x = xdash;
> >  		ppt[0].y = ydash;
> >  		polyi = 1;
> > 
> 
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 

Re: Possible fix for Windows bug #2213362

[Tatsuro M. <tma...@ya...>]

Hello
Fix of a filename of the results file.  

http://www.geocities.co.jp/tmgpltwin/Files/Files.html

0021 F2213362.pdf, 22,378 bytes, 2009-09-06, Results for the patch for the bug ( 2213362 win.trm:
Extra line from end of graph to key sample) by Ethan Merritt (
http://www.nabble.com/Possible-fix-for-Windows-bug--2213362-td25314642.html)

Regards

Tatsuro 
--- Tatsuro MATSUOKA wrote:

> Hello Ethan Merritt 
> 
> I have tested your patch.
> 
> The results are fine.
> Please see
> http://www.geocities.co.jp/tmgpltwin/Files/Files.html
> 
> 0021 2213362.pdf,22,378 bytes, 2009-09-06, Results for the patch for the bug ( 2213362 win.trm:
> Extra
> line from end of graph to key sample) by Ethan Merritt (
> http://www.nabble.com/Possible-fix-for-Windows-bug--2213362-td25314642.html)
> 
> Regards
> 
> Tatsuro
> 
> --- Ethan Merritt  wrote:
> 
> > The win terminal Bug
> > 
> >  2213362  	 win.trm: Extra line from end of graph to key sample
> > 
> > has been with us since 4.2.4.  I really want to get this fixed before
> > putting out a 4.4-rc1.
> > 
> > Could somebody with a Windows build system please test whether the 
> > attachd patch cures it?
> > 
> > In a nutshell, if a line plot connects exactly 199 points (polymax - 1)
> > then an extra line is drawn.   Simple test case:
> > 
> > set term win
> > set key left
> > set samples 199
> > plot x
> > 
> > 		thanks in advance for any assistance,
> > 
> > 				Ethan
> > > diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> > --- gnuplot/src/win/wgraph.c	2009-08-29 14:42:00.000000000 -0700
> > +++ gnuplot-cvs/src/win/wgraph.c	2009-09-05 20:57:28.000000000 -0700
> > @@ -917,6 +917,7 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
> >  	    polyi++;
> >  	    if (polyi >= polymax) {
> >  		Polyline(hdc, ppt, polyi);
> > +		MoveTo(hdc, xdash, ydash);     /* EAM 5 Sept 2009 */
> >  		ppt[0].x = xdash;
> >  		ppt[0].y = ydash;
> >  		polyi = 1;
> > 
> 
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: Possible fix for Windows bug #2213362

[Tatsuro M. <tma...@ya...>]

Hello Ethan Merritt 

I have tested your patch.

The results are fine.
Please see
http://www.geocities.co.jp/tmgpltwin/Files/Files.html

0021 2213362.pdf,22,378 bytes, 2009-09-06, Results for the patch for the bug ( 2213362 win.trm: Extra
line from end of graph to key sample) by Ethan Merritt (
http://www.nabble.com/Possible-fix-for-Windows-bug--2213362-td25314642.html)

Regards

Tatsuro

--- Ethan Merritt  wrote:

> The win terminal Bug
> 
>  2213362  	 win.trm: Extra line from end of graph to key sample
> 
> has been with us since 4.2.4.  I really want to get this fixed before
> putting out a 4.4-rc1.
> 
> Could somebody with a Windows build system please test whether the 
> attachd patch cures it?
> 
> In a nutshell, if a line plot connects exactly 199 points (polymax - 1)
> then an extra line is drawn.   Simple test case:
> 
> set term win
> set key left
> set samples 199
> plot x
> 
> 		thanks in advance for any assistance,
> 
> 				Ethan
> > diff -urp gnuplot/src/win/wgraph.c gnuplot-cvs/src/win/wgraph.c
> --- gnuplot/src/win/wgraph.c	2009-08-29 14:42:00.000000000 -0700
> +++ gnuplot-cvs/src/win/wgraph.c	2009-09-05 20:57:28.000000000 -0700
> @@ -917,6 +917,7 @@ drawgraph(LPGW lpgw, HDC hdc, LPRECT rec
>  	    polyi++;
>  	    if (polyi >= polymax) {
>  		Polyline(hdc, ppt, polyi);
> +		MoveTo(hdc, xdash, ydash);     /* EAM 5 Sept 2009 */
>  		ppt[0].x = xdash;
>  		ppt[0].y = ydash;
>  		polyi = 1;
> 


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Possible fix for Windows bug #2213362

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

The win terminal Bug

 2213362  	 win.trm: Extra line from end of graph to key sample

has been with us since 4.2.4.  I really want to get this fixed before
putting out a 4.4-rc1.

Could somebody with a Windows build system please test whether the 
attachd patch cures it?

In a nutshell, if a line plot connects exactly 199 points (polymax - 1)
then an extra line is drawn.   Simple test case:

set term win
set key left
set samples 199
plot x

		thanks in advance for any assistance,

				Ethan

Re: set key in 4.2.6

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

On Saturday 05 September 2009, Petr Mikulik wrote:
> I've just noticed this new behaviour in 4.2.6:
> 
> gnuplot> set key
>                 ^
>          warning: deprecated syntax, use "set key default"
> 
> 
> This was not happening until recently and neither this happens in cvs. Isn't 
> this a bug?


According to "cvs annotate set.c", it has been that way since 17-May-03.
That was six and a half years ago, even before 4.0 was released.
And I can confirm that 4.0 gives the same error message on that command.
(Yes, I have runnable executables going back to 3.7.2)

set key in 4.2.6

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

I've just noticed this new behaviour in 4.2.6:

gnuplot> set key
                ^
         warning: deprecated syntax, use "set key default"


This was not happening until recently and neither this happens in cvs. Isn't 
this a bug?

---
PM

Re: windows term (and aqua term) bug ? (was colorbar (windows version) in octave ML)

[Ben A. <bpa...@ma...>]

On Sep 4, 2009, at 5:34 PM, Tatsuro MATSUOKA wrote:

> Hello
>
> In the octave ML, it is reported the following bug report concerning  
> gnuplot backend.
>
> http://www.nabble.com/colorbar-(windows-version)-p25168238.html
>
> This problem did not occur in the x11 terminal emf and png  
> terminals. (I have tested only on this tree
> term.)
>
> The same problem have reported by Ben Abbott on the "aqua" terminal  
> on Mac OSX.
> See:
>
> http://www.nabble.com/Re%3A-colorbar-(windows-version)-p25170589.html
> <snip-begin>
> <snip-end>
> Any comments ?
>
> Regards
>
> Tatsuro

Presently, I'm not able to build the developers sources (I haven't  
attempted a build for several days, I'll try now), but I recall that  
it is possible patch Octave to display the colorbar properly for Aqua  
(I assume the same would work for windows).

If my memory is correct, all that is needed is to change the limits  
for the colorbar's short axis by a factor of 2. I do not recall if a  
problem existed for the vertical axis, but if it does I'd expect it  
necessary change to be proportional to the length of the color map.

Ben

windows term (and aqua term) bug ? (was colorbar (windows version) in octave ML)

[Tatsuro M. <tma...@ya...>]

Hello

In the octave ML, it is reported the following bug report concerning gnuplot backend.

http://www.nabble.com/colorbar-(windows-version)-p25168238.html

This problem did not occur in the x11 terminal emf and png terminals. (I have tested only on this tree
term.)

The same problem have reported by Ben Abbott on the "aqua" terminal on Mac OSX.
See:

http://www.nabble.com/Re%3A-colorbar-(windows-version)-p25170589.html

The attachment file is the capture of pipe stream from octave to gnuplot after some modification for
treating it at ease.
This can be used from shell prompt as following

$ cat debug.bin | gnuplot


The text part of debug.bin is shown in the following

**********
unset multiplot;
set terminal GNUTERM enhanced title "Figure 1" 
set output 'foo.txt';
set multiplot;

reset;
set autoscale keepfix;
set origin 0, 0
set size 1, 1
set tmargin screen 0.925;
set bmargin screen 0.11;
set lmargin screen 0.8275;
set rmargin screen 0.874;
unset label;
unset xtics;
unset ytics;
unset ztics;
unset x2tics;
unset x2tics;
unset title;
unset xlabel;
unset x2label;
unset ylabel;
unset y2label;
unset zlabel;
set grid noxtics;
set grid noy2tics;
set grid noztics;
set grid nomxtics;
set grid nomy2tics;
set grid nomztics;
set grid front;
set border front;
unset grid;
unset xtics;
unset mxtics;
unset x2tics;
unset mx2tics;
set format y2 "%g";
set y2tics border in scale  1.4 mirror  font ",12";
unset my2tics;
unset ytics;
unset mytics;
set format z "%g";
set ztics border in scale  1.4 mirror  font ",12";
unset mztics;
unset logscale x;
unset logscale y2;
unset logscale z;
set clip two;
set pm3d implicit;
set hidden3d;
set xrange [0.000000000000000e+000:1.000000000000000e+000] noreverse;
set yrange [0.000000000000000e+000:1.000000000000000e+000] noreverse;
set y2range [0.000000000000000e+000:1.000000000000000e+000] noreverse;
set cbrange [1:64];
set border 431;
set border lw 0.500000;
unset key;
set style data lines;
set palette positive color model RGB maxcolors 64;
set palette file "-" binary record=64 using 1:2:3:4;
 (binary data deleted)
unset colorbox;
plot "-" binary array=2x64 scan=yx origin=(0,0.0078125) dx=1 dy=0.015625 using 1 title "" with image;
\
;
(binary data deleted)
set bmargin screen 0.11;
set lmargin screen 0.13;
set rmargin screen 0.75;
unset label;
unset xtics;
unset ytics;
unset ztics;
unset x2tics;
unset x2tics;
unset title;
unset xlabel;
unset x2label;
unset ylabel;
unset y2label;
unset zlabel;
set grid noxtics;
set grid noytics;
set grid noztics;
set grid nomxtics;
set grid nomytics;
set grid nomztics;
set grid layerdefault;
set border back;
unset grid;
set format x "%g";
set xtics border in scale  1.4 mirror  font ",12";
unset mxtics;
unset x2tics;
unset mx2tics;
set format y "%g";
set ytics border in scale  1.4 mirror  font ",12";
unset mytics;
unset y2tics;
unset my2tics;
set format z "%g";
set ztics border in scale  1.4 mirror  font ",12";
unset mztics;
unset logscale x;
unset logscale y;
unset logscale z;
set clip two;
set pm3d implicit;
set hidden3d;
set xrange [0.000000000000000e+000:1.000000000000000e+000] noreverse;
set yrange [0.000000000000000e+000:1.000000000000000e+000] noreverse;
set cbrange [0:1];
set border 431;
set border lw 0.500000;
unset key;
set style data lines;
set palette positive color model RGB maxcolors 64;
set palette file "-" binary record=64 using 1:2:3:4;
(binary data deleted)
unset colorbox;
plot "-";
Inf Inf
e
pause 30
************

Any comments ?

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: launch help in pdf or on web

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

On Friday 04 September 2009 00:27:22 Petr Mikulik wrote:

> Nowadays, there are GUIs for gnuplot running under other systems, i.e. wxt 
> and qt. That would be nice if their menus can launch the interactive help 
> files,  i.e. help in PDF (using default pdf reader) or help on web (using  
> default html browser). 

I think you have pointed to the heart of the problem.
How is an application program like gnuplot supposed to know what the "default"
application launcher is?  The match-up of mimetype to preferred application
is a desktop- or system-level function.  I have no clue about Windows,
but on many linux desktop configurations you can select with the mouse
any text string that is a well-formed URL and it will give you the option
to launch a browser. From this perspective it would be sufficient to do:
gnuplot> help foo
         Please see http://gnuplot.sourceforge.net/docs/gnuplot.pdf

Re: transparent lines and points

[Mojca M. <moj...@gm...>]

On Fri, Sep 4, 2009 at 02:31, Ethan Merritt wrote:
> On Thursday 03 September 2009 16:35:28 Mojca Miklavec wrote:
>> Hello,
>>
>> there are dozens of demos using transparent objects in gnuplot, but I
>> don't remember seing support for drawing transparent lines. Is that
>> possible?
>
> It is not possible.
> Transparency is currently implemented as a property of the fill style,
> not the color or linetype.  So only filled objects can make use of it.

Thanks. My suspects were true, but there have been quite some recent
changes, so I wasn't sure. (And this image is almost trying to
convince someone that transparency is doable with lines ...
http://gnuplot.sourceforge.net/demo_4.3/rgbalpha.1.png.)

> I think it would be straightforward to extend the newer rgb color support
> to full rgba support. That would get you transparent everything.
> But it would be a fair amount of work and touch every terminal driver.

I was (a bit naively) testing if
    withcolor rgba "#0000ff66"
was already working since I was last implementing color support in terminal.

> An intermediate possibility might be to have the solid point types
> honor the current fill style.

It's an interesting idea as a temporary hack, but something I would
vote against for a general implementation. For TeX (and possibly
others) the solid point types are no different than non-solid ones.

> Then you could at least have transparent
> circles, squares, and triangles.  I am not certain how much work that
> would be.  Again it would potentially touch every terminal driver that
> can handle solid points.

I'm fully aware of the fact that implementing transparency would mean
fixing almost every single terminal where one would require support
for that, yes.
But just honoring solid point types is a bad idea. I can imagine something like
    set style line 1 lc rgba "#0000ffcc"
or similar that would have equal influence on both lines and points.
Changing just solid point types is a bad idea.

Thank you,
    Mojca

launch help in pdf or on web

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

Gnuplot on OS/2 and Windows had always an interactive (GUI) help reader for 
their INF and HLP help formats, respectively. Nowadays, MS removed the 32 
bit HLP reader from the default Windows Vista installation and it has to be 
installed separately. Is it easy to switch the format to 16 bit HLP (for 
which WinHelp.exe is still installed by default)? Or shell we ship the CHM 
help file (is there an appropriate convertor for gnuplot formats? I've 
googled one shareware hlp2chm.exe.)?

Nowadays, there are GUIs for gnuplot running under other systems, i.e. wxt 
and qt. That would be nice if their menus can launch the interactive help 
files, i.e. help in PDF (using default pdf reader) or help on web (using 
default html browser). Possible new menu items could be:
- Help in PDF
- Help on web
- Demos on web
- Faq on web

Or will this be a job for the GUIs or for new gnuplot commands? E.g.

helppdf splot
helpweb splot

---
PM

Re: www.gnuplot.info domain (was: Re: 4.2.6 released)

[Philipp K. J. <ja...@ie...>]

On Thursday 03 September 2009 06:13:01 pm Allin Cottrell wrote:
> On Thu, 3 Sep 2009, Philipp K. Janert wrote:
> > On this matter (since I was recently very confused
> > about this):
> >
> > The domain at www.gnuplot.info points to a mirror
> > of the gnuplot main site at gnuplot.sourceforge.net.
>
> Aha, that explains it.  It seems odd to have the "official"
> gnuplot site (well, the #1 google hit) be a mirror of the
> "primary" site, with a lag of up to 24 hours.

I completely agree - I never knew this either.

I don't mind the mirroring (although I don't see
the need for it either), but I do mind that it is 
not more clearly stated.

>
> On the gretl page that references gnuplot I've now switched the
> URI to point to gnuplot.sourceforge.net.
>
> Allin Cottrell

Re: 4.2.6 released

[Tatsuro M. <tma...@ya...>]

Hello

--- Allin Cottrell wrote:

> Please also tell www.gnuplot.info, which is still showing 4.2.5 as
> the latest release.  (Yes, I know how tedious it is to get all
> these ducks in a row!)

I found the source and document the below

http://sourceforge.net/projects/gnuplot/files/

Regards

Tatsuro

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: transparent lines and points

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

On Thursday 03 September 2009 16:35:28 Mojca Miklavec wrote:
> Hello,
> 
> there are dozens of demos using transparent objects in gnuplot, but I
> don't remember seing support for drawing transparent lines. Is that
> possible?

It is not possible.
Transparency is currently implemented as a property of the fill style,
not the color or linetype.  So only filled objects can make use of it.

I think it would be straightforward to extend the newer rgb color support
to full rgba support. That would get you transparent everything.
But it would be a fair amount of work and touch every terminal driver.

An intermediate possibility might be to have the solid point types
honor the current fill style.  Then you could at least have transparent
circles, squares, and triangles.  I am not certain how much work that
would be.  Again it would potentially touch every terminal driver that
can handle solid points.

> I have the same question regarding transparent points, but I guess
> that drawing "with circles" might be the easiest choice in that case
> (if transparent points are not supported).

	Ethan

Re: www.gnuplot.info domain (was: Re: 4.2.6 released)

[Allin C. <cot...@wf...>]

On Thu, 3 Sep 2009, Philipp K. Janert wrote:

> On this matter (since I was recently very confused
> about this):
>
> The domain at www.gnuplot.info points to a mirror
> of the gnuplot main site at gnuplot.sourceforge.net.

Aha, that explains it.  It seems odd to have the "official"
gnuplot site (well, the #1 google hit) be a mirror of the
"primary" site, with a lag of up to 24 hours.

On the gretl page that references gnuplot I've now switched the
URI to point to gnuplot.sourceforge.net.

Allin Cottrell

www.gnuplot.info domain (was: Re: 4.2.6 released)

[Philipp K. J. <ja...@ie...>]

On this matter (since I was recently very confused
about this):

The domain at www.gnuplot.info points to a mirror
of the gnuplot main site at gnuplot.sourceforge.net.

This mirror is currently hosted by Virginia Tech and
administered by Clark Gaylord (who also owns the
gnuplot.info domain). Clark assures me that the
mirror is refreshed once a day.

Clark suggests that Virginia Tech provides better
internet connectivity than sourceforge, hence the
mirror. (I am in no position to judge the accuracy
of this statement.)

Personally, I have been confused that gnuplot.info
is a mirror - I always thought it was a mere alias for
the main site. 

(If nobody objects, I will put a note explaining the 
relationship between the two sites into the 
documentation page on the gnuplot website.)

Best,

		Ph.






On Thursday 03 September 2009 04:25:18 pm Allin Cottrell wrote:
> On Thu, 3 Sep 2009, Ethan Merritt wrote:
> > Gnuplot version 4.2.6 is released as of today.
> >
> > SourceForge has totally re-worked the process for putting out a release.
> > Making the actual files available for download is now much easier.
> > Unfortunately, I can't find an equivalent to the old button
> > "E-mail an announcement to everyone who requested notification".
> >
> > So tell all your friends :-)
>
> Please also tell www.gnuplot.info, which is still showing 4.2.5 as
> the latest release.  (Yes, I know how tedious it is to get all
> these ducks in a row!)
>
> Allin Cottrell
>
> ---------------------------------------------------------------------------
>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment - and
> focus on what you do best, core application coding. Discover what's new
> with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta