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

Re: x11: border lw 0 vs lw 1 for lt -1

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

On Sunday 09 December 2007 06:10, Petr Mikulik wrote:
> > Not in the core. All the XResource interpretation is done in gnuplot_x11.
> > The routine that manages linewidths is pr_width().
> > 
> > > Further it seems that this is actually a multiplicate constant, not a line
> > > width in pixels as  "help x11 line" describes. Is this right?
> > 
> > Yes, that has always annoyed me.  But if you set all the XResource linewidths
> > to 1.0, then the multiplicative constant is effectively the true linewidth.
> > So most people probably don't notice.
> > 
> > I would be in favor changing it so that
> >     'set term x11; plot foo lt 3 lw 5'
> > really does use a linewidth of 5 pixels rather than using
> > (5 * getR(db,"linewidth3"))
> 
> I like prefer this as well.

Unfortunately it turns out that this doesn't work.
If we change the code to use the linewidths passed by the core driver
directly, then the default linewidths are never used.  That makes the
XResource values for default linewidths useless.

A related possibility is to add a global linewidth multiplier in the
core driver:
	set term x11 linewidth LW
That way if you want all the lines to be thicker, you can set this from 
inside gnuplot rather than having to use xrdb to change the values of
gnuplot*linewidthN in the XResource database.
Many other drivers already work like this.


-- 
Ethan A Merritt

Re: bug in wx terminal for linewidth 0

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

On Sunday 09 December 2007 06:18, Petr Mikulik wrote:
> I think the limit should be "lw 1" -- thus, all linewidths < 1 should be 
> equivalent to linewidth 1. I seems that all terminals work this way.

This is not true for PostScript or PDF.

PostScript (the language, not the terminal driver) has the rule
"0 linewidth means as thin as the device supports".
So on a 1200dpi printer, linewidth 0 produces  about the same as
linewidth 0.06  

-- 
Ethan A Merritt

Re: bug in wx terminal for linewidth 0

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

> > It seems that WXT is incorrectly setting the linewidth 0 to be really a zero 
> > thickness, instead of the smallest linewidth achievable (as all other 
> > terminals are doing).
> >
> > Compare:
> >
> > plot sin(x) w l lw 0, cos(x) w l lw 1
> > set term wxt; replot
> > set term png size 900,700; set out 'a.png'; replot
> > set term post color; set out 'a.ps'; replot
> > set term fig color; set out 'a.fig'; replot
> 
> I don't know what's the proper answer to this, but from "help linestyle" 
> I can read:
> "The line width and point size are multipliers for the default width and 
> size"
> And the smallest achievable linewidth for cairo-based terminals is 
> definetely zero. It is a consequence of antialiasing. For example, try:
> 
> plot x-2 lw 3 lt 1, x-1 lw 2 lt 1, x lw 1 lt 1, x+1 lw .8 lt 1, x+2 lw 
> .5 lt 1, x+3 lw .3 lt 1, x+4 lw .1 lt 1, x+5 lw .03 lt 1
> 
> You will probably see that even at lw 0.03 the line is visible and looks 
> indeed very thin.

All these lines below lw 1 have thickness 1 pixel, but they are lighter 
(I had a look by "kmag"). 

> Do you think we should decided of a lower bound on the linewidth for 
> cairo-based terminals ?

I think the limit should be "lw 1" -- thus, all linewidths < 1 should be 
equivalent to linewidth 1. I seems that all terminals work this way.

---
PM

Re: x11: border lw 0 vs lw 1 for lt -1

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

> Not in the core. All the XResource interpretation is done in gnuplot_x11.
> The routine that manages linewidths is pr_width().
> 
> > Further it seems that this is actually a multiplicate constant, not a line
> > width in pixels as  "help x11 line" describes. Is this right?
> 
> Yes, that has always annoyed me.  But if you set all the XResource linewidths
> to 1.0, then the multiplicative constant is effectively the true linewidth.
> So most people probably don't notice.
> 
> I would be in favor changing it so that
>     'set term x11; plot foo lt 3 lw 5'
> really does use a linewidth of 5 pixels rather than using
> (5 * getR(db,"linewidth3"))

I like prefer this as well.

---
PM

Re: Pseudofile for vectors

[Peter D. <pc...@wi...>]

On Sat, Dec 08, 2007 at 03:24:32PM -0800, Ethan A Merritt wrote:
> Does it really need an extra column of pseudodata?

You need two dimensions of sampling for something like this:

    http://wikisophia.org/wiki/User:Danenberg#Vector_field

That hack was only possible by splotting to get an extra column out of
'+', and flattening to 2d with `set view map':

    splot '+' using 1:2:(0.0):(cos($1)):(cos($2)):(0.0) with vectors

Problem is that for 3d vectorfields, there's no 4d analog of splot to
flatten into a cube.

Re: Pseudofile for vectors

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

On Saturday 08 December 2007 02:09, Peter Danenberg wrote:
> I'd like to detect whether plot/splot has been called 'with vectors'
> and generate an extra column of data from the pseudofile '+'.

Hmm. Does it really need an extra column of pseudodata?
What were you going to put there?
I understand that you need additional columns in the using specifier,
but I don't see how you could autogenerate these from the x/y grid
sampling.  Aren't they entirely specific to the function you are plotting?
For example, this isn't a very useful plot but it show that you can 
generate vector plots:

   plot [-8:8] '+' using ($1):(sin($1)):(cos($1)):(sin($1)) with vector
 
> Problem is that by the time df_generate_pseudodata() is called,
> df_current_plot isn't set; so I can't simply check whether
> df_current_plot->plot_style == VECTOR.

Heh.  Until about 2 days ago, df_current_plot was _never_ set, except
in the one special case of 2D histograms.  Earlier this week I realized 
by consistently setting df_current_plot from df_open(), not only could
the histogram code be cleaned up but also two outstanding bugs could be
fixed.  So as of 5 December, df_current_plot should be available for
all plots to check.   Please try again using current CVS.

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

Re: x11: border lw 0 vs lw 1 for lt -1

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

On Saturday 08 December 2007 00:46, Petr Mikulik wrote:
> >
> > The default has been that way since at least version 3.7
> > The relevant X resource is:
> > 
> >   gnuplot*borderWidth: 2
> 
> Looking to the source code ([bB]order[wW]idth] appears in gplt_x11.c, 
> x11.trm and be.trm), I wonder how this option is implemented... I don't see 
> that it sets any global variable in the gnuplot core.

Not in the core. All the XResource interpretation is done in gnuplot_x11.
The routine that manages linewidths is pr_width().

> Further it seems that this is actually a multiplicate constant, not a line
> width in pixels as  "help x11 line" describes. Is this right?

Yes, that has always annoyed me.  But if you set all the XResource linewidths
to 1.0, then the multiplicative constant is effectively the true linewidth.
So most people probably don't notice.

I would be in favor changing it so that
    'set term x11; plot foo lt 3 lw 5'
really does use a linewidth of 5 pixels rather than using
(5 * getR(db,"linewidth3"))


> Additionally, this indicates:
> 
> src/gplt_x11.c:    {"-borderwidth", ".borderwidth", XrmoptionSepArg, 
> (XPointer) NULL},
> src/gplt_x11.c:    {"-bw", ".borderwidth", XrmoptionSepArg, (XPointer) 
> NULL},
> 
> that
> 	gnuplot -bw 5
> would set the default border to the number indicated, but it does nothing.

That seems to be a typo.  The lines should read (note capitalization)
    {"-borderwidth", ".borderWidth", XrmoptionSepArg, (XPointer) NULL},
    {"-bw", ".borderWidth", XrmoptionSepArg, (XPointer) NULL},

> Further, there are
>     { "-iconic", hasNoArg}, { "-rv", hasNoArg},
>    { "-selectionTimeout", hasArg}, 
>     { "-name", hasArg},
> and other potential command line options which are not documented
> in "help x11 line".

Aren't these generic X11 resource names that have nothing in 
particular to do with gnuplot?  The docs say:

  For terminal type `x11`, `gnuplot` accepts (when initialized) the standard
  X Toolkit options and resources such as geometry, font, and name from the
  command line arguments or a configuration file.  See the X(1) man page
  (or its equivalent) for a description of such options.

For example:
  gnuplot -bg #AAAAAA -geometry 250x250 -iconic

works as expected without requiring any special code in gnuplot_x11.

-- 
Ethan A Merritt

Re: bug in wx terminal for linewidth 0

[<tim...@lp...>]

Petr Mikulik a écrit :
> It seems that WXT is incorrectly setting the linewidth 0 to be really a zero 
> thickness, instead of the smallest linewidth achievable (as all other 
> terminals are doing).
>
> Compare:
>
> plot sin(x) w l lw 0, cos(x) w l lw 1
> set term wxt; replot
> set term png size 900,700; set out 'a.png'; replot
> set term post color; set out 'a.ps'; replot
> set term fig color; set out 'a.fig'; replot
>
> ---
> PM
>   

Hi Petr,

I don't know what's the proper answer to this, but from "help linestyle" 
I can read:
"The line width and point size are multipliers for the default width and 
size"
And the smallest achievable linewidth for cairo-based terminals is 
definetely zero. It is a consequence of antialiasing. For example, try:

plot x-2 lw 3 lt 1, x-1 lw 2 lt 1, x lw 1 lt 1, x+1 lw .8 lt 1, x+2 lw 
.5 lt 1, x+3 lw .3 lt 1, x+4 lw .1 lt 1, x+5 lw .03 lt 1

You will probably see that even at lw 0.03 the line is visible and looks 
indeed very thin.
Do you think we should decided of a lower bound on the linewidth for 
cairo-based terminals ?

Best regards,

Timothée

Pseudofile for vectors

[Peter D. <pc...@wi...>]

I'd like to detect whether plot/splot has been called 'with vectors'
and generate an extra column of data from the pseudofile '+'.

Problem is that by the time df_generate_pseudodata() is called,
df_current_plot isn't set; so I can't simply check whether
df_current_plot->plot_style == VECTOR.

Is there any other way to determine the plot style other than mucking
around in the option parser to set a global?


P.S. The attached patch dodges the issue entirely by simply producing
two columns of data; but this results in superfluous data for
one-variable functions.

Re: x11: border lw 0 vs lw 1 for lt -1

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

> > It seems to me that X11 is having thick linewidth 1 for the border:
> > 	set border 4095 lw 0; splot x
> > 	set term x11 2
> > 	set border 4095 lw 1; splot x
> > For other terminals (ps, png, windows), the border thicknesses 0 and 1 are 
> > both thin.
> > 
> > Try
> > 	plot sin(x) w l lt 0 lw 0, sin(x)+0.1 w l lt -1 lw 1
> > on different terminals. It seems that only the X11 produces a thick line for 
> > linetype -1. Is there a reason for this?
>
> The default has been that way since at least version 3.7
> The relevant X resource is:
> 
>   gnuplot*borderWidth: 2

Looking to the source code ([bB]order[wW]idth] appears in gplt_x11.c, 
x11.trm and be.trm), I wonder how this option is implemented... I don't see 
that it sets any global variable in the gnuplot core. Further it seems that 
this is actually a multiplicate constant, not a line width in pixels as 
"help x11 line" describes. Is this right?

Additionally, this indicates:

src/gplt_x11.c:    {"-borderwidth", ".borderwidth", XrmoptionSepArg, 
(XPointer) NULL},
src/gplt_x11.c:    {"-bw", ".borderwidth", XrmoptionSepArg, (XPointer) 
NULL},

that
	gnuplot -bw 5
would set the default border to the number indicated, but it does nothing.

Further, there are
    { "-iconic", hasNoArg}, { "-rv", hasNoArg},
   { "-selectionTimeout", hasArg}, 
    { "-name", hasArg},
and other potential command line options which are not documented
in "help x11 line".

---
PM

bug in wx terminal for linewidth 0

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

It seems that WXT is incorrectly setting the linewidth 0 to be really a zero 
thickness, instead of the smallest linewidth achievable (as all other 
terminals are doing).

Compare:

plot sin(x) w l lw 0, cos(x) w l lw 1
set term wxt; replot
set term png size 900,700; set out 'a.png'; replot
set term post color; set out 'a.ps'; replot
set term fig color; set out 'a.fig'; replot

---
PM

Re: x11: border lw 0 vs lw 1 for lt -1

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

On Friday 07 December 2007 14:07, Petr Mikulik wrote:
> It seems to me that X11 is having thick linewidth 1 for the border:
> 	set border 4095 lw 0; splot x
> 	set term x11 2
> 	set border 4095 lw 1; splot x
> For other terminals (ps, png, windows), the border thicknesses 0 and 1 are 
> both thin.
> 
> Try
> 	plot sin(x) w l lt 0 lw 0, sin(x)+0.1 w l lt -1 lw 1
> on different terminals. It seems that only the X11 produces a thick line for 
> linetype -1. Is there a reason for this?

The default has been that way since at least version 3.7
The relevant X resource is:

  gnuplot*borderWidth: 2

-- 
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

x11: border lw 0 vs lw 1 for lt -1

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

It seems to me that X11 is having thick linewidth 1 for the border:
	set border 4095 lw 0; splot x
	set term x11 2
	set border 4095 lw 1; splot x
For other terminals (ps, png, windows), the border thicknesses 0 and 1 are 
both thin.

Try
	plot sin(x) w l lt 0 lw 0, sin(x)+0.1 w l lt -1 lw 1
on different terminals. It seems that only the X11 produces a thick line for 
linetype -1. Is there a reason for this?

---
PM

Re: a patch for "splot title N"

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

On Tuesday 04 December 2007 11:20, Ethan Merritt wrote:
> On Tuesday 04 December 2007 02:09, Shigeharu TAKENO wrote:
> > shige 12/04 2007
> > ----------------
> > 
> > The command 'plot' can read the plot title in the key box from a 
> > datafile by by "title column(N)" or "title N" in 2D (plot), but 
> > 'splot' cannot.
> > 
> > I think 'splot' can read by the following patch (for CVS version
> > of gnuplot):
> 
> Yes, this is a good idea.
> 
> But there is a small problem with your patch.  By default it takes the
> title from the 2nd column of the data file.  This is correct for a 2D
> plot, but for a 3D plot it should take the title from the 3rd column.

I can see that will be difficult to fix this.  The 2D/3D information is not
available inside df_readline().  That was originally intentional, but it
causes problems for some of gnuplot's newer features.  

Therefore I will add your patch to CVS now, and later we can try to figure
out how datafile.c can detect a 3D plot context.  We may end up having
to pass a pointer to the plot header into df_readline().


 
> Test case:
> 
>    set key autotitle columnheader
>    plot 'foo.dat'  using 1:2           # title comes from column 2 (correct)
>    splot 'foo.dat' using 1:2:3         # title comes from column 2 (error)
> 
> 
> Could you fix that, and upload the patch to SourceForge?
> 
> 	thanks
> 
> 		Ethan Merritt
> 		<sf...@us...>
> 
> 
>  
> > ----- From here -----
> > diff -uN gnuplot-current/src/datafile.c.ORG gnuplot-current/src/datafile.c
> > --- gnuplot-current/src/datafile.c.ORG	Tue Dec  4 18:46:31 2007
> > +++ gnuplot-current/src/datafile.c	Tue Dec  4 18:48:06 2007
> > @@ -2727,6 +2727,22 @@
> >      plot->title_no_enhanced = !keyT.enhanced;
> >  }
> >  
> > +/* shige */
> > +void
> > +df_set_key_title3(struct surface_points *plot)
> > +{
> > +    /* What if there was already a title specified? */
> > +    if (plot->title && !plot->title_is_filename)
> > +	return;
> > +    if (plot->title_is_suppressed)
> > +	return;
> > +    if (plot->title)
> > +	free(plot->title);
> > +
> > +    plot->title = gp_strdup(df_key_title);
> > +    plot->title_no_enhanced = !keyT.enhanced;
> > +}
> > +
> >  static void
> >  df_parse_string_field(char *string, char *field)
> >  {
> > diff -uN gnuplot-current/src/datafile.h.ORG gnuplot-current/src/datafile.h
> > --- gnuplot-current/src/datafile.h.ORG	Tue Dec  4 18:46:31 2007
> > +++ gnuplot-current/src/datafile.h	Tue Dec  4 18:47:13 2007
> > @@ -117,6 +117,8 @@
> >  int df_3dmatrix __PROTO((struct surface_points *, int));
> >  #ifdef EAM_DATASTRINGS
> >  void df_set_key_title __PROTO((struct curve_points *));
> > +/* shige */
> > +void df_set_key_title3 __PROTO((struct surface_points *));
> >  int expect_string __PROTO((const char column ));
> >  #endif
> >  
> > diff -uN gnuplot-current/src/plot3d.c.ORG gnuplot-current/src/plot3d.c
> > --- gnuplot-current/src/plot3d.c.ORG	Tue Dec  4 18:46:32 2007
> > +++ gnuplot-current/src/plot3d.c	Tue Dec  4 18:48:39 2007
> > @@ -746,6 +746,19 @@
> >  		}
> >  		continue;
> >  	    }
> > +/* shige */
> > +#ifdef EAM_DATASTRINGS
> > +	    else if (j == DF_FOUND_KEY_TITLE){
> > +		df_set_key_title3(this_plot);
> > +		continue;
> > +	    }
> > +	    else if (j == DF_KEY_TITLE_MISSING){
> > +		fprintf(stderr,
> > +			"get_data: key title not found in requested column\n"
> > +		    );
> > +		continue;
> > +	    }
> > +#endif
> >  
> >  	    /* its a data point or undefined */
> >  	    if (xdatum >= local_this_iso->p_max) {
> > @@ -1495,6 +1508,8 @@
> >  		int_error(c_token, "duplicated or contradicting arguments in plot options");
> >  
> >  	    /* set default values for title if this has not been specified */
> > +	    /* shige */
> > +	    this_plot->title_is_filename = FALSE;
> >  	    if (!set_title) {
> >  		this_plot->title_no_enhanced = TRUE; /* filename or function cannot be enhanced */
> >  		if (key->auto_titles == FILENAME_KEYTITLES) {
> > @@ -1515,6 +1530,8 @@
> >  			xtitle = this_plot->title;
> >  		    else if (crnt_param == 1)
> >  			ytitle = this_plot->title;
> > +		    /* shige */
> > +		    this_plot->title_is_filename = TRUE;
> >  		} else {
> >  		    if (xtitle != NULL)
> >  			xtitle[0] = '\0';
> > ----- To here -----
> > 
> > +========================================================+
> >  Shigeharu TAKENO     NIigata Institute of Technology
> >                        kashiwazaki,Niigata 945-1195 JAPAN
> >  sh...@ie...   TEL(&FAX): +81-257-22-8161
> > +========================================================+
> > 
> > -------------------------------------------------------------------------
> > SF.Net email is sponsored by: The Future of Linux Business White Paper
> > from Novell.  From the desktop to the data center, Linux is going
> > mainstream.  Let it simplify your IT future.
> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> > _______________________________________________
> > 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: a patch for "splot title N"

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

On Tuesday 04 December 2007 02:09, Shigeharu TAKENO wrote:
> shige 12/04 2007
> ----------------
> 
> The command 'plot' can read the plot title in the key box from a 
> datafile by by "title column(N)" or "title N" in 2D (plot), but 
> 'splot' cannot.
> 
> I think 'splot' can read by the following patch (for CVS version
> of gnuplot):

Yes, this is a good idea.

But there is a small problem with your patch.  By default it takes the
title from the 2nd column of the data file.  This is correct for a 2D
plot, but for a 3D plot it should take the title from the 3rd column.

Test case:

   set key autotitle columnheader
   plot 'foo.dat'  using 1:2           # title comes from column 2 (correct)
   splot 'foo.dat' using 1:2:3         # title comes from column 2 (error)


Could you fix that, and upload the patch to SourceForge?

	thanks

		Ethan Merritt
		<sf...@us...>


 
> ----- From here -----
> diff -uN gnuplot-current/src/datafile.c.ORG gnuplot-current/src/datafile.c
> --- gnuplot-current/src/datafile.c.ORG	Tue Dec  4 18:46:31 2007
> +++ gnuplot-current/src/datafile.c	Tue Dec  4 18:48:06 2007
> @@ -2727,6 +2727,22 @@
>      plot->title_no_enhanced = !keyT.enhanced;
>  }
>  
> +/* shige */
> +void
> +df_set_key_title3(struct surface_points *plot)
> +{
> +    /* What if there was already a title specified? */
> +    if (plot->title && !plot->title_is_filename)
> +	return;
> +    if (plot->title_is_suppressed)
> +	return;
> +    if (plot->title)
> +	free(plot->title);
> +
> +    plot->title = gp_strdup(df_key_title);
> +    plot->title_no_enhanced = !keyT.enhanced;
> +}
> +
>  static void
>  df_parse_string_field(char *string, char *field)
>  {
> diff -uN gnuplot-current/src/datafile.h.ORG gnuplot-current/src/datafile.h
> --- gnuplot-current/src/datafile.h.ORG	Tue Dec  4 18:46:31 2007
> +++ gnuplot-current/src/datafile.h	Tue Dec  4 18:47:13 2007
> @@ -117,6 +117,8 @@
>  int df_3dmatrix __PROTO((struct surface_points *, int));
>  #ifdef EAM_DATASTRINGS
>  void df_set_key_title __PROTO((struct curve_points *));
> +/* shige */
> +void df_set_key_title3 __PROTO((struct surface_points *));
>  int expect_string __PROTO((const char column ));
>  #endif
>  
> diff -uN gnuplot-current/src/plot3d.c.ORG gnuplot-current/src/plot3d.c
> --- gnuplot-current/src/plot3d.c.ORG	Tue Dec  4 18:46:32 2007
> +++ gnuplot-current/src/plot3d.c	Tue Dec  4 18:48:39 2007
> @@ -746,6 +746,19 @@
>  		}
>  		continue;
>  	    }
> +/* shige */
> +#ifdef EAM_DATASTRINGS
> +	    else if (j == DF_FOUND_KEY_TITLE){
> +		df_set_key_title3(this_plot);
> +		continue;
> +	    }
> +	    else if (j == DF_KEY_TITLE_MISSING){
> +		fprintf(stderr,
> +			"get_data: key title not found in requested column\n"
> +		    );
> +		continue;
> +	    }
> +#endif
>  
>  	    /* its a data point or undefined */
>  	    if (xdatum >= local_this_iso->p_max) {
> @@ -1495,6 +1508,8 @@
>  		int_error(c_token, "duplicated or contradicting arguments in plot options");
>  
>  	    /* set default values for title if this has not been specified */
> +	    /* shige */
> +	    this_plot->title_is_filename = FALSE;
>  	    if (!set_title) {
>  		this_plot->title_no_enhanced = TRUE; /* filename or function cannot be enhanced */
>  		if (key->auto_titles == FILENAME_KEYTITLES) {
> @@ -1515,6 +1530,8 @@
>  			xtitle = this_plot->title;
>  		    else if (crnt_param == 1)
>  			ytitle = this_plot->title;
> +		    /* shige */
> +		    this_plot->title_is_filename = TRUE;
>  		} else {
>  		    if (xtitle != NULL)
>  			xtitle[0] = '\0';
> ----- To here -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

a patch for "splot title N"

[Shigeharu T. <sh...@ie...>]

shige 12/04 2007
----------------

The command 'plot' can read the plot title in the key box from a 
datafile by by "title column(N)" or "title N" in 2D (plot), but 
'splot' cannot.

I think 'splot' can read by the following patch (for CVS version
of gnuplot):

----- From here -----
diff -uN gnuplot-current/src/datafile.c.ORG gnuplot-current/src/datafile.c
--- gnuplot-current/src/datafile.c.ORG	Tue Dec  4 18:46:31 2007
+++ gnuplot-current/src/datafile.c	Tue Dec  4 18:48:06 2007
@@ -2727,6 +2727,22 @@
     plot->title_no_enhanced = !keyT.enhanced;
 }
 
+/* shige */
+void
+df_set_key_title3(struct surface_points *plot)
+{
+    /* What if there was already a title specified? */
+    if (plot->title && !plot->title_is_filename)
+	return;
+    if (plot->title_is_suppressed)
+	return;
+    if (plot->title)
+	free(plot->title);
+
+    plot->title = gp_strdup(df_key_title);
+    plot->title_no_enhanced = !keyT.enhanced;
+}
+
 static void
 df_parse_string_field(char *string, char *field)
 {
diff -uN gnuplot-current/src/datafile.h.ORG gnuplot-current/src/datafile.h
--- gnuplot-current/src/datafile.h.ORG	Tue Dec  4 18:46:31 2007
+++ gnuplot-current/src/datafile.h	Tue Dec  4 18:47:13 2007
@@ -117,6 +117,8 @@
 int df_3dmatrix __PROTO((struct surface_points *, int));
 #ifdef EAM_DATASTRINGS
 void df_set_key_title __PROTO((struct curve_points *));
+/* shige */
+void df_set_key_title3 __PROTO((struct surface_points *));
 int expect_string __PROTO((const char column ));
 #endif
 
diff -uN gnuplot-current/src/plot3d.c.ORG gnuplot-current/src/plot3d.c
--- gnuplot-current/src/plot3d.c.ORG	Tue Dec  4 18:46:32 2007
+++ gnuplot-current/src/plot3d.c	Tue Dec  4 18:48:39 2007
@@ -746,6 +746,19 @@
 		}
 		continue;
 	    }
+/* shige */
+#ifdef EAM_DATASTRINGS
+	    else if (j == DF_FOUND_KEY_TITLE){
+		df_set_key_title3(this_plot);
+		continue;
+	    }
+	    else if (j == DF_KEY_TITLE_MISSING){
+		fprintf(stderr,
+			"get_data: key title not found in requested column\n"
+		    );
+		continue;
+	    }
+#endif
 
 	    /* its a data point or undefined */
 	    if (xdatum >= local_this_iso->p_max) {
@@ -1495,6 +1508,8 @@
 		int_error(c_token, "duplicated or contradicting arguments in plot options");
 
 	    /* set default values for title if this has not been specified */
+	    /* shige */
+	    this_plot->title_is_filename = FALSE;
 	    if (!set_title) {
 		this_plot->title_no_enhanced = TRUE; /* filename or function cannot be enhanced */
 		if (key->auto_titles == FILENAME_KEYTITLES) {
@@ -1515,6 +1530,8 @@
 			xtitle = this_plot->title;
 		    else if (crnt_param == 1)
 			ytitle = this_plot->title;
+		    /* shige */
+		    this_plot->title_is_filename = TRUE;
 		} else {
 		    if (xtitle != NULL)
 			xtitle[0] = '\0';
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: about arrow heads in gnuplot

[<HBB...@t-...>]

Manjari Bagchi wrote:

> Could you please tell me how I can draw an arrow with two heads of
> different styles in gnuplot.

You can't.  You could draw two arrows in opposite directions, each with 
a differently styled head, though.

pgnuplot for octave

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

Hello

The previous mail included a lot of type mistakes.
Please ignore it.

The current octave for windows distribution, the Michael's modified pgnuplot was used.
That is independent of wgnuplot and which has both abilities of pipe receiving and the plotting
system.
  That is because the current octave all plotting data to the gnuplot via pipe.   The combination of
the pgnuplot and the wgnuplot cannot be used.  The incoming data speed is fairly larger than the
wgnuplot interpret the command from the wgnuplot command terminal.

However we sometimes want to use the latest version gnuplot like cvs one for example distributed by
prof.Kakuto.

Url of mirror site:

http://www.ring.gr.jp/pub/text/TeX/ptex-win32/utils/
gnuplot-43pl0w32.zip

 
The patch attached that used in the test for the successive plot from the octave.

I think that the current pgnuplot is not suitable for this purpose and not effective.
The command will be better to be interpreted by line to line.  
I have set waiting factor by each line.
I used the Sleep function, however even sleep(1), the wait time is enough but it can to be shortened.

I would like to hear the gnuplot persons' opinions.

Sincerely yours,

Tatsuro MATSUOKA


--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

pgnuplot for octave

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

Hello

The current octave for windows distribution, the Michael's modified pgnuplot was used.
That is indpendent of wgnuplot and which has both abilities of pipe receiving and the plotting system.
  That is because the current octave all plotting data to the gnuplot via pipe.   The combination of
the pgnuplot and the wgnuplot cannot be used.  The incomming data speed is fairly larger than the
wgnuplot interpret the command from the wgnuplot command terminal.

However we sometimes want use current version gnuplot like cvs one for exaple distributed by prof.
Kakuto.

Url of mirror site:

http://www.ring.gr.jp/pub/text/TeX/ptex-win32/utils/
gnuplot-43pl0w32.zip

 
The patch attached that used the test for the sucesive plot from octave.

I think that the current pgnuplot is not suitable for this purpose and not effective.
The command will be interpreted by line to line.  I set wating factor by each line.
I used the Sleep function, however even sleep(1), the wait time is enough but I this it will be enough
to be shortened.

I would like to hear the gnuplot persons' opinions.

Sincerely yours,

Tatsuro MATSUOKA





  

--------------------------------------
New Design Yahoo! JAPAN  2008/01/01
http://pr.mail.yahoo.co.jp/newdesign/

about arrow heads in gnuplot

[Manjari B. <ma...@ti...>]

Hi,

Could you please tell me how I can draw an arrow with two heads of
different styles in gnuplot.

With best regards,
Manjari
-- 
=====================================
" Be who you are and say what you feel, because
  those who mind don't matter and those who
  matter don't mind. "
 ~~~  Theodor Seuss Geisel
=====================================
 Manjari Bagchi
 Homepage:  http://www.tifr.res.in/~manjari/
 Visiting Fellow,
 Department of Astronomy and Astrophysics
 Tata Institute of Fundamental Research
 Homi Bhaba Road,
 Colaba, Mumbai 400005, India
           -------------------
Phone: +91 22 2278 2289
Fax: +91 22 2280 4610 / 11
email (official): ma...@ti...
 email (personal): man...@gm...
===============================

Re: New functionality needed?

[<HBB...@t-...>]

Ethan Merritt wrote:

> 1) allow an option "noautoscale" associated with each item in the
>    plot command:
> 	plot A, B, C noautoscale, D no autoscale

Sounds reasonable.

> 2) provide a lock-to-primary-axis option for axes x2 and y2.
>    This would allow a sequence of plot commands like
>         set xrange [*:*]
>         set yrange [*:*]
>         set y2range locked
>         set x2range locked

I would consider that an abuse of the secondary axes.

Re: pngcairo: suggestion for additional option

[<HBB...@t-...>]

Allin Cottrell wrote:

> Should I take this comment as a "vote" in favor of handling this 
> issue by means of a new variable in the terminal structure rather 
> than a new function pointer?

Yes.

> That is, Ethan has (I think) alluded to things other than a simple 
> scale factor, that specific terminals might want to provide.  A 
> function pointer is inherently extensible, 

Not really.  An API entry point created with the pre-existing intention 
of extending it later, in some as yet unkown way, is basically a 
declaration of capitulation.  It states "I don't know how to design 
this, so I won't design it at all."

As soon as you add features to the function, you just end up having to 
do exactly what the terminal API was explicitly designed *not* to need: 
to patch up all drivers that already have the new function to cover its 
new aspect.

> but if we add a variable to handle scale, it's possible we might end
> up having to add more variables to cope with fancier variants on the
> basic idea.

That's exactly how the system is supposed to be used, yes.

New functionality needed?

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

Here is a request I have seen on the newsgroup in the past. 
Now I am wanting it myself for some dynamically-created plots.

Say you are plotting some sets of data A, B, C, D.
The data in sets A and B are of primary interest, and you
want to auto-scale the axes to capture their full range.
C and D are for reference only (perhaps previous measurements
of two different classes).  You want these on the plot for
comparison, but one or both may be way out of the range of A and B.

So we want to autoscale the axes to the contents of A and B.
C and D should be on that same scale, but should *not* affect autoscaling.
 
The only way I know of to do this now involves multiple passes.
  1) plot A and B with autoscale;  save the x/y range information
  2) replot A, B, C, D using previously saved ranges.
This does work. But it is awkward, particularly for volatile data,
where we need an extra step of first making a snapshot of A and B.

I am thinking about possible changes that would provide an easier path

1) allow an option "noautoscale" associated with each item in the
   plot command:
	plot A, B, C noautoscale, D no autoscale

2) provide a lock-to-primary-axis option for axes x2 and y2.
   This would allow a sequence of plot commands like
        set xrange [*:*]
        set yrange [*:*]
        set y2range locked
        set x2range locked
        plot A, B, C axes x2y2, D axes x2y2

Any thoughts or preferences between the two, or suggestions for a
different approach?

Have I overlooked a less obvious option that already exists?


-- 
Ethan A Merritt

Re: pngcairo: suggestion for additional option

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

On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote:

> Allin Cottrell wrote:
> > On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote:
> 
> > > Same difference.  Adding a variable at the end of the struct 
> > > has the same net effect, and the benefit of being less 
> > > risky.  An unsupported variable automatically defaults to 
> > > zero, but an unsupported function defaults to an invalid 
> > > function pointer, which is generally unsafe to use.
> 
> > I thought things were set up so that an unsupported function 
> > defaults to a null pointer (and my proposed code tests for 
> > that).
> 
> Correct.  More to the point, as long as new elements only get 
> added at the end of the struct, every unsupported member 
> defaults to a zero of the approriate type.  Numeric variables 
> end up as zero, pointers as null pointers.
> 
> > On the other hand, having the scale variable default to zero 
> > would not be good at all -- it should really default to 1, 
> > though I suppose one could work around a broken default of 0.
> 
> Testing for variable == 0 is no harder than testing for function 
> pointer == 0.

Granted; we can assume that scale == 0 means scale == 1. 

Should I take this comment as a "vote" in favor of handling this 
issue by means of a new variable in the terminal structure rather 
than a new function pointer?

If so, I have only one other point to suggest to the contrary.  
That is, Ethan has (I think) alluded to things other than a simple 
scale factor, that specific terminals might want to provide.  A 
function pointer is inherently extensible, but if we add a 
variable to handle scale, it's possible we might end up having to 
add more variables to cope with fancier variants on the basic 
idea.

I'll be travelling from tomorrow till mid-December, so please 
don't take lack of further responses on this topic to indicate 
lack of interest!  I really would like to see this settled, one 
way or the other.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: pngcairo: suggestion for additional option

[<HBB...@t-...>]

Allin Cottrell wrote:
> On Tue, 27 Nov 2007, Hans-Bernhard Bröker wrote:

>> Same difference.  Adding a variable at the end of the struct has 
>> the same net effect, and the benefit of being less risky.  An 
>> unsupported variable automatically defaults to zero, but an 
>> unsupported function defaults to an invalid function pointer, 
>> which is generally unsafe to use.

> I thought things were set up so that an unsupported function 
> defaults to a null pointer (and my proposed code tests for that).  

Correct.  More to the point, as long as new elements only get added at 
the end of the struct, every unsupported member defaults to a zero of 
the approriate type.  Numeric variables end up as zero, pointers as null 
pointers.

> On the other hand, having the scale variable 
> default to zero would not be good at all -- it should really 
> default to 1, though I suppose one could work around a broken 
> default of 0.

Testing for variable == 0 is no harder than testing for function pointer 
== 0.