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

transparent lines and points

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

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?

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).

Thank you,
    Mojca

Re: 4.2.6 released

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

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

4.2.6 released

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

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 :-)

	Ethan (sf...@us...)









   	           GNUPLOT VERSION 4.2.6
	    ===================================

Version 4.2.6 is an incremental update to the current official base
release gnuplot version 4.2.   

This is expected to be the final update to the 4.2 series;
the next release will be version 4.4

A synopsis of changes since the previous release is given below and in the
NEWS file.  Full information is given in the ChangeLog.

New features, changes and fixes in gnuplot version 4.2.6
===========================================================
* NEW xterm tektronix emulation 'set term xterm'
* FIX off-by-one pixel bug in width of boxes with palette or rgb color
* FIX center rotation of 'set view equal xyz' mode at screen center
* FIX sanity-check time ranges for axes with timeformat
* FIX pslatex blacktext and broken format specifier
* FIX PostScript code points for Lcaron, lcaron in encoding cp1250
* CHANGE If a 2D plot uses a Z-based palette, then autoscale cbrange
* CHANGE aquaterm accepts "size xx,yy" with a comma
* CHANGE Remove the EXPERIMENTAL flag from the wxt terminal
* CHANGE Remove the EXPERIMENTAL flag from the x11 terminal binary polygon mode


Demo plots illustrating these and other features are online at

	http://gnuplot.sourceforge.net/demo_4.2/

You can download a source tarball for gnuplot version 4.2.5 from the 
gnuplot development site on SourceForge.

	http://sourceforge.net/project/showfiles.php?group_id=2055


Installation
------------
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-4.2.6 ; ./configure ; make
test it:
		make check
install it:
		make install


Known issues
------------

- Internationalization and locale support is incomplete in version 4.2.
  If you encounter problems with character encodings, numerical formats,
  or other locale issues, try the CVS development branch on SourceForge.

- Octave has recently changed its method of sending data to gnuplot for
  plotting; data is passed in-line through the pipe to gnuplot's stdin.
  Unfortunately, the current Gnuplot 4.2 code does not support mouse
  interaction with in-line data.  This problem is fixed in the development
  branch, and the fix will appear in version 4.4.

Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

There is also an active gnuplot discussion forum on usenet group

	comp.graphics.apps.gnuplot

Development
-----------
Gnuplot development is quite active. The development branch on SourceForge
contains preliminary implementations of many new features.  At the time of
this release, the development branch is identified as version 4.3.
When version 4.4 is released, the development branch will be relabeled 4.5.
Feedback and contributions of code are very welcome.

Re: 3D grid draw order and latex label string width

[Pierre <pie...@ya...>]

Hi,

The following command (with layerdefault) :
 set border 31
 set style line 10 lt 1 lw 1 lc rgb "green"
 set grid layerdefault ls 10
 splot 1 w pm3d notitle

still produce the layer problem on mirrored axes.


--- En date de : Mar 1.9.09, Thomas Sefzick <t.s...@fz...> a écrit :

De: Thomas Sefzick <t.s...@fz...>
Objet: Re: 3D grid draw order and latex label string width
À: gnu...@li...
Date: Mardi 1 Septembre 2009, 9h28


set grid layerdefault


Pierre-78 wrote:
> 
> ...
> 1-Consider the following minimal example :
>     set border 31
>     set style line 10 lt 1 lw 1 lc rgb "green"
>     set grid back ls 10
>     splot 1 w pm3d notitle
> It gives the result of file 'grid.png' attached to the mail. The (green)
> grid is drawn over the x, y and z axes. Is there a mean to avoid this
> behavior ?
> ...
> 

-- 
View this message in context: http://www.nabble.com/3D-grid-draw-order-and-latex-label-string-width-tp25087447p25235573.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
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: 3D grid draw order and latex label string width

[Thomas S. <t.s...@fz...>]

set grid layerdefault


Pierre-78 wrote:
> 
> ...
> 1-Consider the following minimal example :
>     set border 31
>     set style line 10 lt 1 lw 1 lc rgb "green"
>     set grid back ls 10
>     splot 1 w pm3d notitle
> It gives the result of file 'grid.png' attached to the mail. The (green)
> grid is drawn over the x, y and z axes. Is there a mean to avoid this
> behavior ?
> ...
> 

-- 
View this message in context: http://www.nabble.com/3D-grid-draw-order-and-latex-label-string-width-tp25087447p25235573.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: Labels plotstyle increases line style

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

On Monday 31 August 2009 13:14:54 Benjamin Lindner wrote:
> Ethan Merritt wrote:
> > On Monday 31 August 2009 11:26:16 Benjamin Lindner wrote:

> > Which brings us to labels...
> > One of the properties of a label is  {{no}point}, which controls whether or
> > not a point is drawn exactly at the coordinates given.  If you select to
> > have a point drawn for each label, the point properties have to come from
> > somewhere and the obvious place is to take them from the "linestyle" of the
> > current plot.
> 
> This is true, but if no point is drawn, then increasing the linetype is 
> an unneccesary side effect.
> 
> > So, for example, you might draw a plot containing many labeled data sets,
> > and distinguish which point is from which dataset by the color/shape of the
> > associated points.  Make sense?
> 
> For this example you sketch, yes.
> But let me sketch a different example: Let's say you plot your data 
> using a plotstyle involving some kind of graphical means, e.g. 
> histograms, or lines or linespoints. So the distinction between 
> different sets of data is already properly done by different colour 
> and/or different point types. Now you want to simply add numerical 
> labels to your e.g. histograms because you want to also print the actual 
> numerical value along with the bars. Then simply adding the labels 
> changes the line types and colours of your previous plot, even if no 
> additional line or point is drawn by adding the labels - just the text 
> is printed.
> Then this is not what I would expect. It's an application of labels as 
> simply additional text to an exisiting graph.

From my point of view, consistency requires that every clause of a plot command
consumes one increment of line type.   Another example of this that is close to
what you describe:

    set style data lines
    plot "A.dat", "B.dat", "C.dat", "D.dat"

Suppose you run this script periodically, each time plotting the current
contents of files A, B, C, and D.   Also suppose that for whatever reason
sometimes one or more of the files is empty.   By requiring that each clause
of the plot command increments the color (linestyle), you end up with
consistent colors for all four data sets in every plot, even if not all of
them are present in every plot.

If you were to skip the increment just because in this particular plot no
lines of that color are being drawn, then it would mess up the overall
consistency of the line type assignments.  

The same is true for your labeling case.  You may "know" externally
that the labels you are adding should not be assigned a separate color
because they are paired with a particular plot that already has a color.
But how is gnuplot itself supposed to know this if you don't tell it?
In general if you add a clause to the plot command it describes a new set of
data and should get its own color assignment.

Of course, you are always free to specify an explicit color and/or
line style for each individual plot clause.  Or in this case I suppose
you could just add the label clauses at the end of the command, where 
they will not affect the order of the earlier ones.

	Ethan

Re: Labels plotstyle increases line style

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Monday 31 August 2009 11:26:16 Benjamin Lindner wrote:
>> Hello list,
>>
>> I came across a (for me) strange behaviour, which is, that if you use 
>> the "labels" plotstyle increases the linestyle, although no line is drawn.
> 
> That is entirely expected, but only if you realize that "linestyle" and
> "linetype" have evolved into misnomers.   The linestyle or linetype is
> described by a structure that specifies far more than just the color.
> From term_api.h:
> 
> typedef struct lp_style_type {  /* contains all Line and Point properties */
>     int     pointflag;          /* 0 if points not used, otherwise 1 */
>     int     l_type;
>     int     p_type;
>     int     p_interval;         /* Every Nth point in style LINESPOINTS */
>     double  l_width;
>     double  p_size;
>     TBOOLEAN use_palette;
>     struct t_colorspec pm3d_color;
>     /* ... more to come ? */
> } lp_style_type;
> 
> 
> The thing is, these properties affect points just as much as they affect
> lines per se.  You still have to draw the point with some linewidth and
> some color, right?  For that matter, what about plots "with linespoints"
> where the same set of properties applies to both the lines and the points.
> 
> Which brings us to labels...
> One of the properties of a label is  {{no}point}, which controls whether or
> not a point is drawn exactly at the coordinates given.  If you select to
> have a point drawn for each label, the point properties have to come from
> somewhere and the obvious place is to take them from the "linestyle" of the
> current plot.

This is true, but if no point is drawn, then increasing the linetype is 
an unneccesary side effect.

> So, for example, you might draw a plot containing many labeled data sets,
> and distinguish which point is from which dataset by the color/shape of the
> associated points.  Make sense?

For this example you sketch, yes.
But let me sketch a different example: Let's say you plot your data 
using a plotstyle involving some kind of graphical means, e.g. 
histograms, or lines or linespoints. So the distinction between 
different sets of data is already properly done by different colour 
and/or different point types. Now you want to simply add numerical 
labels to your e.g. histograms because you want to also print the actual 
numerical value along with the bars. Then simply adding the labels 
changes the line types and colours of your previous plot, even if no 
additional line or point is drawn by adding the labels - just the text 
is printed.
Then this is not what I would expect. It's an application of labels as 
simply additional text to an exisiting graph.

benjamin

Re: Labels plotstyle increases line style

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

On Monday 31 August 2009 11:26:16 Benjamin Lindner wrote:
> Hello list,
> 
> I came across a (for me) strange behaviour, which is, that if you use 
> the "labels" plotstyle increases the linestyle, although no line is drawn.

That is entirely expected, but only if you realize that "linestyle" and
"linetype" have evolved into misnomers.   The linestyle or linetype is
described by a structure that specifies far more than just the color.
From term_api.h:

typedef struct lp_style_type {  /* contains all Line and Point properties */
    int     pointflag;          /* 0 if points not used, otherwise 1 */
    int     l_type;
    int     p_type;
    int     p_interval;         /* Every Nth point in style LINESPOINTS */
    double  l_width;
    double  p_size;
    TBOOLEAN use_palette;
    struct t_colorspec pm3d_color;
    /* ... more to come ? */
} lp_style_type;


The thing is, these properties affect points just as much as they affect
lines per se.  You still have to draw the point with some linewidth and
some color, right?  For that matter, what about plots "with linespoints"
where the same set of properties applies to both the lines and the points.

Which brings us to labels...
One of the properties of a label is  {{no}point}, which controls whether or
not a point is drawn exactly at the coordinates given.  If you select to
have a point drawn for each label, the point properties have to come from
somewhere and the obvious place is to take them from the "linestyle" of the
current plot.

So, for example, you might draw a plot containing many labeled data sets,
and distinguish which point is from which dataset by the color/shape of the
associated points.  Make sense?

set style data labels

   plot '1.dat' point pt 5, '2.dat' point pt 7, '3.dat' point pt 1

That will give you a plot containing three sets of labeled points.
All the labels will be in the normal (black) font since we haven't done
anything special to do otherwise.  Some will be marked by red squares,
some by green circles, and some by blue crosses.


> I am using a 4.3.0 CVS snapshot version.
> 
> Test case:
> set style data linespoints
> 
> set style line 1 lt 1 lc rgb "red"
> set style line 2 lt 1 lc rgb "green"
> set style line 3 lt 1 lc rgb "blue"
> 
> set label 1 "lines should be red and green" at graph 0.5, 0.9
> 
> set style increment user
> 
> plot '-' u 0:1, '-' u 0:1:1 with labels offset character 0,1,0 , '-' u 0:1
> 1
> 2
> 3
> 4
> 5
> e
> 1
> 2
> 3
> 4
> 5
> e
> 2
> 3
> 4
> 5
> 6
> e
> 
> I would expect the lines to have color red and green, not red and blue.
> 
> I looked at the source code in src/plot2d.c and found that for certain 
> plotstyles this increase of the line style is disabled. However, not for 
> the "labels" plotstyle.
> Is this deliberate?
> May I suggest the following change:
> 
> diff -r d67b4d3fbb86 src/plot2d.c
> --- a/src/plot2d.c	Mon Aug 31 09:08:58 2009 +0200
> +++ b/src/plot2d.c	Mon Aug 31 09:09:17 2009 +0200
> @@ -1975,8 +1975,9 @@
>   		&& this_plot->plot_style != IMAGE
>   		&& this_plot->plot_style != RGBIMAGE
>                   && this_plot->plot_style != RGBA_IMAGE
> +		&& this_plot->plot_style != LABELPOINTS
>   		/* don't increment the default line/point properties if
> -		 * this_plot is an image */
> +		 * this_plot is an image or labels plot */
>   	    ) {
>   		if (this_plot->plot_style & PLOT_STYLE_HAS_POINT)
>   		    ++point_num;
> 
> 
> benjamin


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Emf terminal scales point size with canvas size

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Monday 31 August 2009 11:45:39 Benjamin Lindner wrote:
>> Hello list,
>>
>> In a current 4.3.0 build the emf terminal scales the point size with the 
>> terminal size.
>> This is contrary to what other terminals e.g. png or ps do.
> 
> I think it's more complicated than that.
> Various terminals do various things.  
> Some have a fixed point size (particularly the old plotter drivers where
> the points are drawn via a hardware function).
> Some scale by terminal size.  
> Some (as I recall) scale by font size.
> 
> It seems a reasonable goal to have all the drivers do the same thing,
> but before making any changed I'd like first to see a list of which terminals
> do what right now and how many of them can be easily modified to match
> a common convention for the behaviour.
> 

Well to start the list, I can provide:

term  |  scale ps with term size?  |  scale ps with font size?
--------------------------------------------------------------
  emf           yes                        no
  png           no                         no
  gif           no                         no
jpeg           no                         no
   ps           no                         no
  eps           no                         no


benjamin

Re: Emf terminal scales point size with canvas size

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

On Monday 31 August 2009 11:45:39 Benjamin Lindner wrote:
> Hello list,
> 
> In a current 4.3.0 build the emf terminal scales the point size with the 
> terminal size.
> This is contrary to what other terminals e.g. png or ps do.

I think it's more complicated than that.
Various terminals do various things.  
Some have a fixed point size (particularly the old plotter drivers where
the points are drawn via a hardware function).
Some scale by terminal size.  
Some (as I recall) scale by font size.

It seems a reasonable goal to have all the drivers do the same thing,
but before making any changed I'd like first to see a list of which terminals
do what right now and how many of them can be easily modified to match
a common convention for the behaviour.

	Ethan 


> Testcase:
> set pointsize 2
> 
> set term emf size 512,384
> set output "test512x384.emf"
> plot [0:2*pi] sin(x) with linespoints
> 
> set term emf size 1024,768
> set output "test1024x768.emf"
> plot [0:2*pi] sin(x) with linespoints
> 
> set term post size 16cm,12cm
> set output "test16x12.ps"
> plot [0:2*pi] sin(x) with linespoints
> 
> set term post size 8cm,6cm
> set output "test8x6.ps"
> plot [0:2*pi] sin(x) with linespoints
> 
> set term png size 512,384
> set output "test512x384.png"
> plot [0:2*pi] sin(x) with linespoints
> 
> set term png size 1024,768
> set output "test1024x768.png"
> plot [0:2*pi] sin(x) with linespoints
> 
> set output
> 
> 
> The pointsize in "test1024x768.emf" is visibly larger than in 
> "test512x384.emf", even if one scales both terminals to 100% of their size.
> As the linewidth or the fontsize are independent of the actual terminal 
> size, so I think should the point size be.
> 
> benjamin
> 
> ------------------------------------------------------------------------------
> 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
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: missing declarations and wrong printf specifiers - compiler warnings

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> 
> As I understand it, Timothée's intent was that the cairo code be independent
> of the core gnuplot routines. So this was already fixed in CVS as of last
> week by calling malloc() directly.

Oh, I missed that. Sorry for the noise then.

>> All these are not blocking building, but for the sake of clean code I
>> vote they should be fixed.
> 
> Sure.  Thanks.
> 
> 	Ethan

Excellent, thanks :)
benjamin

Emf terminal scales point size with canvas size

[Benjamin L. <lin...@gm...>]

Hello list,

In a current 4.3.0 build the emf terminal scales the point size with the 
terminal size.
This is contrary to what other terminals e.g. png or ps do.

Testcase:
set pointsize 2

set term emf size 512,384
set output "test512x384.emf"
plot [0:2*pi] sin(x) with linespoints

set term emf size 1024,768
set output "test1024x768.emf"
plot [0:2*pi] sin(x) with linespoints

set term post size 16cm,12cm
set output "test16x12.ps"
plot [0:2*pi] sin(x) with linespoints

set term post size 8cm,6cm
set output "test8x6.ps"
plot [0:2*pi] sin(x) with linespoints

set term png size 512,384
set output "test512x384.png"
plot [0:2*pi] sin(x) with linespoints

set term png size 1024,768
set output "test1024x768.png"
plot [0:2*pi] sin(x) with linespoints

set output


The pointsize in "test1024x768.emf" is visibly larger than in 
"test512x384.emf", even if one scales both terminals to 100% of their size.
As the linewidth or the fontsize are independent of the actual terminal 
size, so I think should the point size be.

benjamin

Labels plotstyle increases line style

[Benjamin L. <lin...@gm...>]

Hello list,

I came across a (for me) strange behaviour, which is, that if you use 
the "labels" plotstyle increases the linestyle, although no line is drawn.

I am using a 4.3.0 CVS snapshot version.

Test case:
set style data linespoints

set style line 1 lt 1 lc rgb "red"
set style line 2 lt 1 lc rgb "green"
set style line 3 lt 1 lc rgb "blue"

set label 1 "lines should be red and green" at graph 0.5, 0.9

set style increment user

plot '-' u 0:1, '-' u 0:1:1 with labels offset character 0,1,0 , '-' u 0:1
1
2
3
4
5
e
1
2
3
4
5
e
2
3
4
5
6
e

I would expect the lines to have color red and green, not red and blue.

I looked at the source code in src/plot2d.c and found that for certain 
plotstyles this increase of the line style is disabled. However, not for 
the "labels" plotstyle.
Is this deliberate?
May I suggest the following change:

diff -r d67b4d3fbb86 src/plot2d.c
--- a/src/plot2d.c	Mon Aug 31 09:08:58 2009 +0200
+++ b/src/plot2d.c	Mon Aug 31 09:09:17 2009 +0200
@@ -1975,8 +1975,9 @@
  		&& this_plot->plot_style != IMAGE
  		&& this_plot->plot_style != RGBIMAGE
                  && this_plot->plot_style != RGBA_IMAGE
+		&& this_plot->plot_style != LABELPOINTS
  		/* don't increment the default line/point properties if
-		 * this_plot is an image */
+		 * this_plot is an image or labels plot */
  	    ) {
  		if (this_plot->plot_style & PLOT_STYLE_HAS_POINT)
  		    ++point_num;


benjamin

Re: missing declarations and wrong printf specifiers - compiler warnings

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

On Monday 31 August 2009 10:54:46 Benjamin Lindner wrote:
> Hello list,
> 
> I paid some attention to the compiler warnings emitted when building
> recent 4.3 and 4.4 gnuplot.
> I am using mingw32/gcc, but I guess it's not platform specific.
> 
> First: two cases of missing declarations:
> in src/wxterminal/gp_cairo_helpers.c the declaration for gp_alloc() is
> missing and
> in src/internal.c the declaration of disp_value() is missing.
> 
> Thr trivial fix is:
> 
> diff -r 8a1e8f758422 src/wxterminal/gp_cairo_helpers.c
> --- a/src/wxterminal/gp_cairo_helpers.c	Wed Jul 08 08:27:14 2009 +0200
> +++ b/src/wxterminal/gp_cairo_helpers.c	Wed Jul 08 08:27:29 2009 +0200
> @@ -49,6 +49,8 @@
> 
>   /* for rgb functions */
>   # include "getcolor.h"
> +/* for gp_alloc */
> +#include "alloc.h"

As I understand it, Timothée's intent was that the cairo code be independent
of the core gnuplot routines. So this was already fixed in CVS as of last
week by calling malloc() directly.


> Second: when building with debugging support (i.e. with -DDEBUG), then
> in scr/gp_cairo.c a pritnf format specifier is not quite correct.
> 
> diff -r cc501863450d src/wxterminal/gp_cairo.c
> --- a/src/wxterminal/gp_cairo.c	Wed Jul 08 08:27:29 2009 +0200
> +++ b/src/wxterminal/gp_cairo.c	Wed Jul 08 08:27:33 2009 +0200
> @@ -1026,7 +1026,7 @@
>   	scale_x = (double)M/fabs( x2 - x1 );
>   	scale_y = (double)N/fabs( y2 - y1 );
> 
> -	FPRINTF((stderr,"M %d N %lf x1 %d y1 %d\n", M, N, x1, y1));
> +	FPRINTF((stderr,"M %d N %d x1 %d y1 %d\n", M, N, x1, y1));
>   	cairo_save( plot->cr );
> 
>   	/* Set clipping boundaries for image copy.

Oops. Got it. Thanks.

> Third: when compiling src/win/wpause.c at line 94, gcc emits an
> "ambiguous if-else clause" and suggests braces.
> I am not too familiar with the code to see where the braces should be
> placed, but the intendation of the code would suggest a change like:
> 
> diff -r cd38a24d39cf src/win/wpause.c
> --- a/src/win/wpause.c	Wed Jul 08 08:27:33 2009 +0200
> +++ b/src/win/wpause.c	Wed Jul 08 08:27:38 2009 +0200
> @@ -91,9 +91,10 @@
> 
>   	    /* calculate remaining time, detect overflow */
>   	    t1 = GetTickCount();
> -	    if (tstop > t0)
> +	    if (tstop > t0) {
>   		if ((t1 >= tstop) || (t1 < t0))
>   		    rc = WAIT_TIMEOUT;
> +	    }
>   	    else
>   		if ((t1 >= tstop) && (t1 < t0))
>   		    rc = WAIT_TIMEOUT;
> 
> 
> All these are not blocking building, but for the sake of clean code I
> vote they should be fixed.

Sure.  Thanks.

	Ethan

Re: correction for makefile.mgw for the change at 2009-08-28

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

On Monday 31 August 2009 10:32:57 Benjamin Lindner wrote:
> 
> Thanks for pointing this out. However, this introduces another (more 
> subtle) error when building with wxwidgets support.
> Currently the object file gp_cairo_helpers.o is listed *both* in 
> CAIRO_OBJS and WX_OBJS, which leads to multiple-definition-errors at 
> link stage when gnuplot os built with wxwidgets support.
> It should be listed only once, and this would be correctly in CAIRO_OBJS 
> (since building with wxt implies building with cairo), and hence removed 
> in WX_OBJS as

Yes, already in CVS. Thanks

missing declarations and wrong printf specifiers - compiler warnings

[Benjamin L. <lin...@gm...>]

Hello list,

I paid some attention to the compiler warnings emitted when building
recent 4.3 and 4.4 gnuplot.
I am using mingw32/gcc, but I guess it's not platform specific.

First: two cases of missing declarations:
in src/wxterminal/gp_cairo_helpers.c the declaration for gp_alloc() is
missing and
in src/internal.c the declaration of disp_value() is missing.

Thr trivial fix is:

diff -r 8a1e8f758422 src/wxterminal/gp_cairo_helpers.c
--- a/src/wxterminal/gp_cairo_helpers.c	Wed Jul 08 08:27:14 2009 +0200
+++ b/src/wxterminal/gp_cairo_helpers.c	Wed Jul 08 08:27:29 2009 +0200
@@ -49,6 +49,8 @@

  /* for rgb functions */
  # include "getcolor.h"
+/* for gp_alloc */
+#include "alloc.h"

  unsigned int * gp_cairo_helper_coordval_to_chars(coordval* image, int
M, int N, t_imagecolor color_mode)
  {

diff -r 6501fb450a65 src/internal.c
--- a/src/internal.c	Wed Jul 08 08:27:38 2009 +0200
+++ b/src/internal.c	Wed Jul 08 08:27:46 2009 +0200
@@ -43,6 +43,7 @@
  # include "gp_time.h"           /* for str(p|f)time */
  #include "command.h"            /* for do_system_func */
  #include "variable.h" /* For locale handling */
+#include "setshow.h"  /* for disp_value */

  #include <math.h>


Second: when building with debugging support (i.e. with -DDEBUG), then
in scr/gp_cairo.c a pritnf format specifier is not quite correct.

diff -r cc501863450d src/wxterminal/gp_cairo.c
--- a/src/wxterminal/gp_cairo.c	Wed Jul 08 08:27:29 2009 +0200
+++ b/src/wxterminal/gp_cairo.c	Wed Jul 08 08:27:33 2009 +0200
@@ -1026,7 +1026,7 @@
  	scale_x = (double)M/fabs( x2 - x1 );
  	scale_y = (double)N/fabs( y2 - y1 );

-	FPRINTF((stderr,"M %d N %lf x1 %d y1 %d\n", M, N, x1, y1));
+	FPRINTF((stderr,"M %d N %d x1 %d y1 %d\n", M, N, x1, y1));
  	cairo_save( plot->cr );

  	/* Set clipping boundaries for image copy.


Third: when compiling src/win/wpause.c at line 94, gcc emits an
"ambiguous if-else clause" and suggests braces.
I am not too familiar with the code to see where the braces should be
placed, but the intendation of the code would suggest a change like:

diff -r cd38a24d39cf src/win/wpause.c
--- a/src/win/wpause.c	Wed Jul 08 08:27:33 2009 +0200
+++ b/src/win/wpause.c	Wed Jul 08 08:27:38 2009 +0200
@@ -91,9 +91,10 @@

  	    /* calculate remaining time, detect overflow */
  	    t1 = GetTickCount();
-	    if (tstop > t0)
+	    if (tstop > t0) {
  		if ((t1 >= tstop) || (t1 < t0))
  		    rc = WAIT_TIMEOUT;
+	    }
  	    else
  		if ((t1 >= tstop) && (t1 < t0))
  		    rc = WAIT_TIMEOUT;


All these are not blocking building, but for the sake of clean code I
vote they should be fixed.
thanks

benjamin

Re: correction for makefile.mgw for the change at 2009-08-28

[Benjamin L. <lin...@gm...>]

Tatsuro MATSUOKA wrote:
> Hello Benjamin
> 
> Thank you for your efforts for 'pngcairo and pdfcairo terminals'.
> However, makefile.mgw caused an error when link stage.
> 
> g++  -shared-libgcc -L/WinDevTools/bin -L/WinDevTools/lib  -L/GnuWin32/lib -L/GnuWin32/bin -s
> -mconsole -o gnuplot.exe a
> lloc.o axis.o binary.o bitmap.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o
> fit.o gadgets.o getc
> olor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o
> parse.o plot.o plo
> t2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o tables.o
> tabulate.o term.o t
> ime.o unset.o util.o util3d.o variable.o version.o gpexecute.o  gp_cairo.o winmain.o wgnuplib.o
> wgraph.o wprinter.o wtex
> t.o wpause.o wmenu.o wgplt_res.o -lkernel32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32
> -ladvapi32\
>          -lgd -ljpeg -lfontconfig -lfreetype -lpng12 -lz /WinDevTools/lib/libiconv.a 
> -LC:/Programs/WinDevTools/lib -lca
> iro   -LC:/Programs/WinDevTools/lib -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0
> -lglib-2.0 -lintl
>  -lstdc++_s
> term.o:term.c:(.text+0x8d9b): undefined reference to `gp_cairo_helper_coordval_to_chars'
> collect2: ld returned 1 exit status
> make: *** [gnuplot.exe] Error 1
> make: Leaving directory `/home/gnuplotcvs/gnuplot/src'
> 
> *******************
> The following is the patch to avoid this error
> *********************************************
> 
> --- makefile.mgw.orig	2009-08-31 10:28:40 +0900
> +++ makefile.mgw	2009-08-31 10:36:30 +0900
> @@ -265,7 +265,7 @@
>  	CAIRO_LIBS = $(shell pkg-config --libs cairo)
>  	PANGO_CFLAGS = $(shell pkg-config --cflags pangocairo)
>  	PANGO_LIBS = $(shell pkg-config --libs pangocairo)
> -	CAIRO_OBJS = gp_cairo.o
> +	CAIRO_OBJS = gp_cairo.o gp_cairo_helpers.o
>  	TERMFLAGS += $(CAIRO_CFLAGS) $(PANGO_CFLAGS)
>  endif
>  
> #****************
> 
> Regards
> 
> Tatsuro
> 

Thanks for pointing this out. However, this introduces another (more 
subtle) error when building with wxwidgets support.
Currently the object file gp_cairo_helpers.o is listed *both* in 
CAIRO_OBJS and WX_OBJS, which leads to multiple-definition-errors at 
link stage when gnuplot os built with wxwidgets support.
It should be listed only once, and this would be correctly in CAIRO_OBJS 
(since building with wxt implies building with cairo), and hence removed 
in WX_OBJS as

diff -r fa3081dc37de config/makefile.mgw
--- a/config/makefile.mgw	Mon Aug 31 10:53:07 2009 +0200
+++ b/config/makefile.mgw	Mon Aug 31 10:54:15 2009 +0200
@@ -279,7 +279,7 @@
  	CFLAGS += -DWXWIDGETS
  	CXXFLAGS += $(shell wx-config --cxxflags)
	WX_LIBS = $(shell wx-config --libs)
-	WX_OBJS = wxt_gui.o gp_cairo_helpers.o
+	WX_OBJS = wxt_gui.o
  endif

  ifdef GNU_RC


benjamin

Re: 3D grid draw order and latex label string width

[Pierre <pie...@ya...>]

Thank you Mojca,

Setting the margin and ajusting the label offset accordingly did the trick !

Regarding problem #1, it looks like a bug in gnuplot itself no ?

Best regards,
Pierre 


--- En date de : Ven 21.8.09, Mojca Miklavec <moj...@gm...> a écrit :

De: Mojca Miklavec <moj...@gm...>
Objet: Re: 3D grid draw order and latex label string width
À: "Pierre" <pie...@ya...>
Cc: gnu...@li...
Date: Vendredi 21 Août 2009, 23h36

On Fri, Aug 21, 2009 at 23:15, Pierre wrote:
>
> 2-I am using Latex to draw labels. Consider the following code :
>     set term epslatex
>     set output "label.eps"
>     set format "\number{%g}\mylongmacrolonglongname{}"

Off-topic: you need to use single quotes if you don't want to escape
characters, but in this particular case you need \\number and
\\mylong...

>     plot x
>     set output
> the resulting epslatex files are attached to the mail. My problem here is
> that gnuplot count the number of chars in the format string, then uses this
> number to determines its width. Is there a way to adjust the width, as in
> the 'width' field of the gnuplot 'key' command ?

In general I don't know of any method to explicitely set the label
width, but you can use
    set margin (set lmargin)
in this particular case. (I may be missing something, so don't trust my claim.)

You can also do
    set format "\\a{%g}"
and then in TeX you define:
    \def\a#1{\number{#1}\mylongmacrolonglongname{}}

which helps in some rare cases.

Mojca



      

Re: gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin

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

Hello

--- Ethan Merritt wrote:

> > I have uploade binaries of the gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and
> cygwin.
> > 
> > Topic
> > The pngcairo and pdfcairo terminals are supported to windows version for the sake of efforts
> of
> > Benjamin Lindner.
> 
> Thank you for your patch, and for your new binaries.
> 	Ethan

I have confirmed the ChangLog and correction of makefile.mgw.
Thanks!!

Tatsuro 

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

Re: gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin

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

On Sunday 30 August 2009, Tatsuro MATSUOKA wrote:
> Hello 
> 
> I have uploade binaries of the gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin.
> 
> Topic
> The pngcairo and pdfcairo terminals are supported to windows version for the sake of efforts of
> Benjamin Lindner.

Thank you for your patch, and for your new binaries.


	Ethan

Re: gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin

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

I have forgotten to describe the web address

Cygwin-1.5 and 1.7 binaris
http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Windows
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/


--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello 
> 
> I have uploade binaries of the gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and
> cygwin.
> 
> Topic
> The pngcairo and pdfcairo terminals are supported to windows version for the sake of efforts of
> Benjamin Lindner.
> (Sorry that the cygwin version does not support them.)
> 
> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
> http://pr.mail.yahoo.co.jp/ec10years/
> 
> ------------------------------------------------------------------------------
> 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
> 


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

gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin

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

Hello 

I have uploade binaries of the gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin.

Topic
The pngcairo and pdfcairo terminals are supported to windows version for the sake of efforts of
Benjamin Lindner.
(Sorry that the cygwin version does not support them.)

Regards

Tatsuro


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

gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin

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

Hello 

I have uploade binaries of the gnuplot 4.3 (cvs) (Latest ChangeLog 2009-08-28) for windows and cygwin.

Topic
The pngcairo and pdfcairo terminals are supported to windows version for the sake of efforts of
Benjamin Lindner.
(Sorry that the cygwin version does not support them.)

Regards

Tatsuro


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

correction for makefile.mgw for the change at 2009-08-28

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

Hello Benjamin

Thank you for your efforts for 'pngcairo and pdfcairo terminals'.
However, makefile.mgw caused an error when link stage.

g++  -shared-libgcc -L/WinDevTools/bin -L/WinDevTools/lib  -L/GnuWin32/lib -L/GnuWin32/bin -s
-mconsole -o gnuplot.exe a
lloc.o axis.o binary.o bitmap.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o
fit.o gadgets.o getc
olor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o
parse.o plot.o plo
t2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o tables.o
tabulate.o term.o t
ime.o unset.o util.o util3d.o variable.o version.o gpexecute.o  gp_cairo.o winmain.o wgnuplib.o
wgraph.o wprinter.o wtex
t.o wpause.o wmenu.o wgplt_res.o -lkernel32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32
-ladvapi32\
         -lgd -ljpeg -lfontconfig -lfreetype -lpng12 -lz /WinDevTools/lib/libiconv.a 
-LC:/Programs/WinDevTools/lib -lca
iro   -LC:/Programs/WinDevTools/lib -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lintl
 -lstdc++_s
term.o:term.c:(.text+0x8d9b): undefined reference to `gp_cairo_helper_coordval_to_chars'
collect2: ld returned 1 exit status
make: *** [gnuplot.exe] Error 1
make: Leaving directory `/home/gnuplotcvs/gnuplot/src'

*******************
The following is the patch to avoid this error
*********************************************

--- makefile.mgw.orig	2009-08-31 10:28:40 +0900
+++ makefile.mgw	2009-08-31 10:36:30 +0900
@@ -265,7 +265,7 @@
 	CAIRO_LIBS = $(shell pkg-config --libs cairo)
 	PANGO_CFLAGS = $(shell pkg-config --cflags pangocairo)
 	PANGO_LIBS = $(shell pkg-config --libs pangocairo)
-	CAIRO_OBJS = gp_cairo.o
+	CAIRO_OBJS = gp_cairo.o gp_cairo_helpers.o
 	TERMFLAGS += $(CAIRO_CFLAGS) $(PANGO_CFLAGS)
 endif
 
#****************

Regards

Tatsuro



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

cont: Updated website w/ book info

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

One more thing: while I was at it, I finally removed
the incorrect statement on the "help.html" page that
the newsgroup "comp.graphics.apps.gnuplot" was
identical to the mailing list "gnu...@li...".

Best,

		Ph.


----------  Forwarded Message  ----------

Subject: Updated website w/ book info
Date: Saturday 29 August 2009
From: "Philipp K. Janert" <ja...@ie...>
To: "gnuplot-beta" <gnu...@li...>


Just as a heads-up to everyone: Now that the book
is available in print, I have updated the information
on the gnuplot.info homepage accordingly, and also
put a link on the documentation page.

The old versions of the index.html and the documentation.html
pages are still there, as "_29Aug2009.html", so that we
can revert if needed.

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

-------------------------------------------------------