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

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

Am Freitag, den 20.02.2009, 23:05 +0100 schrieb Manfred Schwarb:
> Am Donnerstag, den 19.02.2009, 13:08 -0800 schrieb Ethan Merritt:
> > On Thursday 19 February 2009 03:52:38 Manfred Schwarb wrote:
> > > > On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote:
> > > > > 
> > > > > > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> > > > > > >
> > > > > > > your change in term/png.trm of
> > > > > > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > > > > > > font default.
> > > > > > > 
> > > > > > > Now, I can't select the builtin fonts any more.
> > > > > > > I tried
> > > > > > > "set term png small"
> > > > > > > "set term png small font small"
> > > > > > > "set term png font small"
> > > > > > > 
> > > > > > > but I always get Arial as the selected font.
> > > > > > > How to select the builtin fonts?
> > > > > > 
> > > > > > Why would you ever want to?
> > > > > > 
> > > > > 
> > > > > 
> > > > > 1) Because I want to be able to shoot myself into the foot?
> > > > > 
> > > > > 2) Because I don't want blurred text in an otherwise unblurred
> > > > >    plot? I really want terminal-font quality in a pixel plot.
> > > > 
> > > > So why not set the font to whatever you are using in your terminal?
> > > > 
> > > 
> > > How to do? You can only select Truetype fonts. 
> > 
> > That is not correct.  libgd is not limited to TrueType fonts. 
> > The font handling is done via freetype2, which handles quite a 
> > variety of font formats:
> > 	http://freetype.sourceforge.net/freetype2/
> > 
> > > E.g. I'd like to set the 
> > > font to the "6x13" terminal font, and something like
> > > "set term png font '6x13'" does not work, as expected.
> > 
> > On my machine such fonts are installed under the names "Terminal [Bitstream]"
> > and "Terminal [DEC]".  Font installation and naming varies widely, so
> > beyond that I cannot help much.
> 
> OK, it seems libgd supports TTF and Type1 fonts, but not unscalable
> pixel fonts. 
> 
> 
> > 
> > > > > 3) For 90 degree rotated text, font quality for non-builtin
> > > > >    fonts is really bad. 
> > > > 
> > > > That makes no sense to me at all.  The font rendering in libgd
> > > > is identical in the two cases. All that the rotation changes is the
> > > > order in which text pixels are copied across onto the image canvas.
> > > > 90-rotated text should be pixel-for-pixel identical to unrotated text.
> > > > If it isn't, this sounds like a bug that should be filed against libgd
> > > > rather than against gnuplot.
> > > > 
> > > > >    I can send examples if you like. 
> > > > 
> > > > Please do. Please also provide the script that generated them,
> > > > and the version number of libgd against which gnuplot is linked.
> > > > Probably a good idea to send them to the libgd list also.
> > > >
> > > 
> > > I suspect it is a generic issue (or perhaps I simply expect too much
> > > from font rendering machines). I tested with pngcairo, and I got the
> > > same artefact. It's like there is a too coarse or skewed color gradient
> > > when rendering the characters, I don't know.
> > > 
> > > libgd and libcairo are reasonably new, I guess (2.0.36 and 1.4.10).
> > > 
> > > I will attach some plot snipplets to this email, for builtin, ttf 
> > > and cairo. 
> > 
> > But you did not attach the generating script.
> > It seems clear to me from inspection of the "bad" ttf rotated text that
> > the rotation angle is not truly 90.  Without seeing the command that
> > generated this text, I cannot say why that would happen.
> > 
> > It is true that when you rotate text to an arbitrary angle, then the
> > characters become somewhat distorted.  Then again, with the builtin fonts
> > you cannot rotate text to arbitrary angles at all.
> >  
> 
> 
> I figured there are 2 separate issues:
> 
> 1) bad rendering which optically results skewed color gradients:
>    This is purely my own fault, as the thing is a multiplot and
>    with each additional "plot" command all label commands were 
>    executed, which resulted in multiple overlaying labels. 
>    And the labels seem to be additive in the color space, with the
>    obvious result.
>    I.e. I simply forgot to add some "unset label" commands after the
>    "plot" command.
>    Hmmm, actually an implicit "unset label" after every plot command
>    would be more intuitive. And it is probably almost mandatory
>    to "unset label" after an plot command, at least I don't see
>    at the moment any usage of these already plotted labels after the
>    "plot" command.
> 
> 
> 2) As you correctly noted, the strings are somewhat slanted. This only
>    happens with libgd, in cairo mode things are OK. And this issue
>    is something different from issue 1).
>    Interestingly this seems to happen only with recent gnuplot versions.
>    I found a gnuplot 4.3 version of December 2007 on my disk, and this
>    version does correct rendering, although it uses the very same
>    shared libraries (i.e. same libgd.so) as the recent cvs-versions
>    which show this strange slanting.
>    The slanting only occurs in vertical orientation, horizontal strings
>    are always OK.
> 
>    I will try to investigate this a bit further over the weekend, but at
>    the moment I'm a bit clueless.
> 
>    A script which shows this issue (probably it could be reduced even
>    more):
> 
> set encoding iso_8859_1
> 
> #set term pngcairo font 'arial,12' size 900,960
> #set term png truecolor small size 900,960
> set term png truecolor font 'arial,12' size 900,960
> set out "demo.png"
> 
> set multiplot
> set label "DEMO" at screen 0.5,0.98 center font "large"
> set lmargin screen 0.1
> set rmargin screen (1.0-0.1)
> set tmargin screen (1.0-0.0708333-0.234375-0.0791667*4.0)
> set bmargin screen (1.0-0.0708333-0.234375-0.0791667*5.0)
> 
> yoff=(1.0-0.0708333-0.234375-0.0791667*4.5)
> set label "Atmosphärenquerschnitt [hPa]" at screen
> (0.1-6.0*0.0133333),yoff \
>   center rotate textcolor lt -1
> plot [0:180][-15:10] sin(x) notitle with lines lc rgb "#A0A0A0"
> 
> unset multiplot
> set output
> 
> 


I did some binary search, an I got
20080915 good
20080916 bad

the offending patch is:

--- term.c	2008/09/07 04:13:02	1.179
+++ term.c	2008/09/16 05:35:25	1.180
@@ -1,5 +1,5 @@
 #ifndef lint
-static char *RCSid() { return RCSid("$Id: term.c,v 1.179 2008/09/07
04:13:02 sfeam Exp $"); }
+static char *RCSid() { return RCSid("$Id: term.c,v 1.180 2008/09/16
05:35:25 sfeam Exp $"); }
 #endif
 
 /* GNUPLOT - term.c */
@@ -995,9 +995,9 @@
 		    (*t->put_text) (x - fix, y, text);
 	    }
 	}
-	if (angle == TEXT_VERTICAL)
+	if (angle == 90 || angle == TEXT_VERTICAL)
 	    x += t->v_char;
-	else if (-angle == TEXT_VERTICAL)
+	else if (angle == -90 || angle == -TEXT_VERTICAL)
 	    x -= t->v_char;
 	else
 	    y -= t->v_char;



Cheers,
Manfred




> Cheers,
> Manfred
> 
> 
> > > > > 4) If you want to produce light-weight plots for e.g. web applications
> > > > >    (i.e. the fewer bytes the better) you really want to avoid
> > > > >    such truetype fonts.
> > > > 
> > > > Possibly. But I am curious about the weight of that argument.
> > > > Can you provide some numbers that demonstrate a significant difference
> > > > in the output file sizes?  If I compare the output of a 'typical' plot
> > > > from the demo set using "verdana,9" as compared to the "medium" built-in
> > > > font, I get a difference of about 400 bytes out of 8000.  I would gladly
> > > > pay that price, because to my eyes the built-in font is both ugly and
> > > > harder to read.  You have said that your eyes disagree, and I believe you.
> > > > On the other hand, if you are exporting your plots to the rest of the
> > > > world then the question is what does a typical viewer think about it?
> > > > I realize that discussion of font preferences can degenerate into
> > > > intractable differences of opinion, but you must be aware that many
> > > > people prefer anti-aliased text.
> > > > 
> > > 
> > > Size: in a plot with moderate amount of labels, I get:
> > > ttf -> builtin:  -15%
> > > ttf -> cairo:    +40%
> > 
> > The cairo output is a from completely different driver, and a completely
> > different text processing system.  You can compare it if you like, but
> > it is not really relevant to the choice of fonts for the png driver.
> > 
> > > For the attached snipplets, the size differences are much bigger.
> > 
> > The fonts, and the image size itself, are larger for your ttf.png example
> > than for your builtin.png example.  If you color more pixels, then yes the
> > image size is larger. But to blame a larger and heavier font for coloring
> > more pixels is, I think, a bit disingenuous.  On top of that, it is evident
> > that the rotation angle in the ttf example is not exactly 90, which
> > distorts the characters and causes additional rows of pixels to be colored.
> > 
> > Here is what I get:
> >     set term png font "courbd,9"
> >     set output 'rav_courbd.png'
> >     load 'running_avg.dem'
> > ## unsetenv GDFONTPATH
> >     set term png medium
> >     set output 'rav_builtin.png'
> >     load 'running_avg.dem'
> > 
> > chauvet [21] ls -l *.png
> > -rw-rw-r-- 1 merritt merritt 7022 2009-02-19 12:43 rav_builtin.png
> > -rw-rw-r-- 1 merritt merritt 7496 2009-02-19 12:52 rav_courbd.png
> > 
> > So for fonts that are roughly the same style, size, and weight,
> > I get a difference of about 475/7500 = 6% difference in image size. 
> > 
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: segfault with debug enabled on mingw in mouse.c

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

On Sunday 22 February 2009, Benjamin Lindner wrote:

> The compiled version segfaults reproducably in mouse.c. Looking at the 
> code I see that the FPRINTF macro is missing stderr as target stream

Thank you.  Fixed in CVS.

> diff -r cbcfbb8c12b7 src/mouse.c
> --- a/src/mouse.c	Sat Feb 21 18:22:30 2009 +0100
> +++ b/src/mouse.c	Sun Feb 22 15:28:11 2009 +0100
> @@ -299,7 +299,7 @@
>   MousePosToGraphPosReal(int xx, int yy, double *x, double *y, double 
> *x2, double *y2)
>   {
>       if (!is_3d_plot) {
> -	FPRINTF(("POS: plot_bounds.xleft=%i, plot_bounds.xright=%i, 
> plot_bounds.ybot=%i, plot_bounds.ytop=%i\n",
> +	FPRINTF((stderr, "POS: plot_bounds.xleft=%i, plot_bounds.xright=%i, 
> plot_bounds.ybot=%i, plot_bounds.ytop=%i\n",
>   		 plot_bounds.xleft, plot_bounds.xright, plot_bounds.ybot, 
> plot_bounds.ytop));
> 
>   	if (plot_bounds.xright == plot_bounds.xleft)
> @@ -314,7 +314,7 @@
>   	    *y = AXIS_MAPBACK(FIRST_Y_AXIS, yy);
>   	    *y2 = AXIS_MAPBACK(SECOND_Y_AXIS, yy);
>   	}
> -	FPRINTF(("POS: xx=%i, yy=%i  =>  x=%g  y=%g\n", xx, yy, *x, *y));
> +	FPRINTF((stderr, "POS: xx=%i, yy=%i  =>  x=%g  y=%g\n", xx, yy, *x, *y));
> 
>       } else {
>   	/* for 3D plots, we treat the mouse position as if it is
> 
> 
> I also would suggest to add -DDEBUG to CFLAGS in makegile.mgw for a 
> debug-enabled build. Then one can issue simply
>    make -f config/makefile.mgw DEBUG=1
> to generate a version with debugging enabled
> diff -r cbcfbb8c12b7 config/makefile.mgw
> --- a/config/makefile.mgw	Sat Feb 21 18:22:30 2009 +0100
> +++ b/config/makefile.mgw	Sun Feb 22 15:28:11 2009 +0100
> @@ -170,7 +170,7 @@
>   CP = cp -p
> 
>   ifdef DEBUG
> -  CFLAGS += -g
> +  CFLAGS += -g -DDEBUG
>     LDFLAGS += -g
>   else
>     CFLAGS += -O2
> 
> 
> benjamin

-- 
Ethan A Merritt

segfault with debug enabled on mingw in mouse.c

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

Hello,

I tried to build a debug version of the current development sources 
using mingw32.
The compiled version segfaults reproducably in mouse.c. Looking at the 
code I see that the FPRINTF macro is missing stderr as target stream

diff -r cbcfbb8c12b7 src/mouse.c
--- a/src/mouse.c	Sat Feb 21 18:22:30 2009 +0100
+++ b/src/mouse.c	Sun Feb 22 15:28:11 2009 +0100
@@ -299,7 +299,7 @@
  MousePosToGraphPosReal(int xx, int yy, double *x, double *y, double 
*x2, double *y2)
  {
      if (!is_3d_plot) {
-	FPRINTF(("POS: plot_bounds.xleft=%i, plot_bounds.xright=%i, 
plot_bounds.ybot=%i, plot_bounds.ytop=%i\n",
+	FPRINTF((stderr, "POS: plot_bounds.xleft=%i, plot_bounds.xright=%i, 
plot_bounds.ybot=%i, plot_bounds.ytop=%i\n",
  		 plot_bounds.xleft, plot_bounds.xright, plot_bounds.ybot, 
plot_bounds.ytop));

  	if (plot_bounds.xright == plot_bounds.xleft)
@@ -314,7 +314,7 @@
  	    *y = AXIS_MAPBACK(FIRST_Y_AXIS, yy);
  	    *y2 = AXIS_MAPBACK(SECOND_Y_AXIS, yy);
  	}
-	FPRINTF(("POS: xx=%i, yy=%i  =>  x=%g  y=%g\n", xx, yy, *x, *y));
+	FPRINTF((stderr, "POS: xx=%i, yy=%i  =>  x=%g  y=%g\n", xx, yy, *x, *y));

      } else {
  	/* for 3D plots, we treat the mouse position as if it is


I also would suggest to add -DDEBUG to CFLAGS in makegile.mgw for a 
debug-enabled build. Then one can issue simply
   make -f config/makefile.mgw DEBUG=1
to generate a version with debugging enabled

diff -r cbcfbb8c12b7 config/makefile.mgw
--- a/config/makefile.mgw	Sat Feb 21 18:22:30 2009 +0100
+++ b/config/makefile.mgw	Sun Feb 22 15:28:11 2009 +0100
@@ -170,7 +170,7 @@
  CP = cp -p

  ifdef DEBUG
-  CFLAGS += -g
+  CFLAGS += -g -DDEBUG
    LDFLAGS += -g
  else
    CFLAGS += -O2


benjamin

Re: set xtics <incr> has no effect with xtic(n)

[Hans-Bernhard B. <HBB...@t-...>]

Shigeharu TAKENO wrote:
> shige 02/20 2009
> ----------------
> 
> In gnuplot-4.2 or after, I found that the command "set xtics 
> <incr>" has no effect when "xticlabels(n)" is used.

Of course it doesn't.  You either let gnuplot generate the tics, 
controlled by "set xtics" options, or you supply them all yourself, 
either via the long-form

	set xtics (<x1>, <x2>, ...)

command, or via the xticlabels() option to *plot.  The latter makes a 
label for every data point being plotted, just like it says it does.  If 
you don't want so many of them, you'll have to give it fewer data points 
to handle.  The "every" option to *plot may come in handy there.

>  set xtics 5
>  plot 'data' using 0:2 with lp
> 
> This makes skipped labels at x=0,5,10,... 

There's nothing "skipped" about those tics.  You get tics ever 5 units 
of x axis, period.

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

Am Donnerstag, den 19.02.2009, 13:08 -0800 schrieb Ethan Merritt:
> On Thursday 19 February 2009 03:52:38 Manfred Schwarb wrote:
> > > On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote:
> > > > 
> > > > > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> > > > > >
> > > > > > your change in term/png.trm of
> > > > > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > > > > > font default.
> > > > > > 
> > > > > > Now, I can't select the builtin fonts any more.
> > > > > > I tried
> > > > > > "set term png small"
> > > > > > "set term png small font small"
> > > > > > "set term png font small"
> > > > > > 
> > > > > > but I always get Arial as the selected font.
> > > > > > How to select the builtin fonts?
> > > > > 
> > > > > Why would you ever want to?
> > > > > 
> > > > 
> > > > 
> > > > 1) Because I want to be able to shoot myself into the foot?
> > > > 
> > > > 2) Because I don't want blurred text in an otherwise unblurred
> > > >    plot? I really want terminal-font quality in a pixel plot.
> > > 
> > > So why not set the font to whatever you are using in your terminal?
> > > 
> > 
> > How to do? You can only select Truetype fonts. 
> 
> That is not correct.  libgd is not limited to TrueType fonts. 
> The font handling is done via freetype2, which handles quite a 
> variety of font formats:
> 	http://freetype.sourceforge.net/freetype2/
> 
> > E.g. I'd like to set the 
> > font to the "6x13" terminal font, and something like
> > "set term png font '6x13'" does not work, as expected.
> 
> On my machine such fonts are installed under the names "Terminal [Bitstream]"
> and "Terminal [DEC]".  Font installation and naming varies widely, so
> beyond that I cannot help much.

OK, it seems libgd supports TTF and Type1 fonts, but not unscalable
pixel fonts. 


> 
> > > > 3) For 90 degree rotated text, font quality for non-builtin
> > > >    fonts is really bad. 
> > > 
> > > That makes no sense to me at all.  The font rendering in libgd
> > > is identical in the two cases. All that the rotation changes is the
> > > order in which text pixels are copied across onto the image canvas.
> > > 90-rotated text should be pixel-for-pixel identical to unrotated text.
> > > If it isn't, this sounds like a bug that should be filed against libgd
> > > rather than against gnuplot.
> > > 
> > > >    I can send examples if you like. 
> > > 
> > > Please do. Please also provide the script that generated them,
> > > and the version number of libgd against which gnuplot is linked.
> > > Probably a good idea to send them to the libgd list also.
> > >
> > 
> > I suspect it is a generic issue (or perhaps I simply expect too much
> > from font rendering machines). I tested with pngcairo, and I got the
> > same artefact. It's like there is a too coarse or skewed color gradient
> > when rendering the characters, I don't know.
> > 
> > libgd and libcairo are reasonably new, I guess (2.0.36 and 1.4.10).
> > 
> > I will attach some plot snipplets to this email, for builtin, ttf 
> > and cairo. 
> 
> But you did not attach the generating script.
> It seems clear to me from inspection of the "bad" ttf rotated text that
> the rotation angle is not truly 90.  Without seeing the command that
> generated this text, I cannot say why that would happen.
> 
> It is true that when you rotate text to an arbitrary angle, then the
> characters become somewhat distorted.  Then again, with the builtin fonts
> you cannot rotate text to arbitrary angles at all.
>  


I figured there are 2 separate issues:

1) bad rendering which optically results skewed color gradients:
   This is purely my own fault, as the thing is a multiplot and
   with each additional "plot" command all label commands were 
   executed, which resulted in multiple overlaying labels. 
   And the labels seem to be additive in the color space, with the
   obvious result.
   I.e. I simply forgot to add some "unset label" commands after the
   "plot" command.
   Hmmm, actually an implicit "unset label" after every plot command
   would be more intuitive. And it is probably almost mandatory
   to "unset label" after an plot command, at least I don't see
   at the moment any usage of these already plotted labels after the
   "plot" command.


2) As you correctly noted, the strings are somewhat slanted. This only
   happens with libgd, in cairo mode things are OK. And this issue
   is something different from issue 1).
   Interestingly this seems to happen only with recent gnuplot versions.
   I found a gnuplot 4.3 version of December 2007 on my disk, and this
   version does correct rendering, although it uses the very same
   shared libraries (i.e. same libgd.so) as the recent cvs-versions
   which show this strange slanting.
   The slanting only occurs in vertical orientation, horizontal strings
   are always OK.

   I will try to investigate this a bit further over the weekend, but at
   the moment I'm a bit clueless.

   A script which shows this issue (probably it could be reduced even
   more):

set encoding iso_8859_1

#set term pngcairo font 'arial,12' size 900,960
#set term png truecolor small size 900,960
set term png truecolor font 'arial,12' size 900,960
set out "demo.png"

set multiplot
set label "DEMO" at screen 0.5,0.98 center font "large"
set lmargin screen 0.1
set rmargin screen (1.0-0.1)
set tmargin screen (1.0-0.0708333-0.234375-0.0791667*4.0)
set bmargin screen (1.0-0.0708333-0.234375-0.0791667*5.0)

yoff=(1.0-0.0708333-0.234375-0.0791667*4.5)
set label "Atmosphärenquerschnitt [hPa]" at screen
(0.1-6.0*0.0133333),yoff \
  center rotate textcolor lt -1
plot [0:180][-15:10] sin(x) notitle with lines lc rgb "#A0A0A0"

unset multiplot
set output


Cheers,
Manfred


> > > > 4) If you want to produce light-weight plots for e.g. web applications
> > > >    (i.e. the fewer bytes the better) you really want to avoid
> > > >    such truetype fonts.
> > > 
> > > Possibly. But I am curious about the weight of that argument.
> > > Can you provide some numbers that demonstrate a significant difference
> > > in the output file sizes?  If I compare the output of a 'typical' plot
> > > from the demo set using "verdana,9" as compared to the "medium" built-in
> > > font, I get a difference of about 400 bytes out of 8000.  I would gladly
> > > pay that price, because to my eyes the built-in font is both ugly and
> > > harder to read.  You have said that your eyes disagree, and I believe you.
> > > On the other hand, if you are exporting your plots to the rest of the
> > > world then the question is what does a typical viewer think about it?
> > > I realize that discussion of font preferences can degenerate into
> > > intractable differences of opinion, but you must be aware that many
> > > people prefer anti-aliased text.
> > > 
> > 
> > Size: in a plot with moderate amount of labels, I get:
> > ttf -> builtin:  -15%
> > ttf -> cairo:    +40%
> 
> The cairo output is a from completely different driver, and a completely
> different text processing system.  You can compare it if you like, but
> it is not really relevant to the choice of fonts for the png driver.
> 
> > For the attached snipplets, the size differences are much bigger.
> 
> The fonts, and the image size itself, are larger for your ttf.png example
> than for your builtin.png example.  If you color more pixels, then yes the
> image size is larger. But to blame a larger and heavier font for coloring
> more pixels is, I think, a bit disingenuous.  On top of that, it is evident
> that the rotation angle in the ttf example is not exactly 90, which
> distorts the characters and causes additional rows of pixels to be colored.
> 
> Here is what I get:
>     set term png font "courbd,9"
>     set output 'rav_courbd.png'
>     load 'running_avg.dem'
> ## unsetenv GDFONTPATH
>     set term png medium
>     set output 'rav_builtin.png'
>     load 'running_avg.dem'
> 
> chauvet [21] ls -l *.png
> -rw-rw-r-- 1 merritt merritt 7022 2009-02-19 12:43 rav_builtin.png
> -rw-rw-r-- 1 merritt merritt 7496 2009-02-19 12:52 rav_courbd.png
> 
> So for fonts that are roughly the same style, size, and weight,
> I get a difference of about 475/7500 = 6% difference in image size. 
> 

Re: fitting functions with more independent variables

[James R. V. Z. <jr...@co...>]

After I posted the notice about my patch for fit.c, I got this report:

> I tried to access the files, e.g., at Mon, 16 Feb 2009 14:00:45 -0800,
> and get
>    Address Not Found
>    Firefox can't find the server at jrv.oddones.org.
> nslookup gives
>    ** server can't find jrv.oddones.org: NXDOMAIN
> and there does not appear to be any link to the files from the
> oddones.org homepage.

The problem has been cleared up.  If anyone else tripped over this,
please try again.  Here again are the links:

       http://jrv.oddones.org/fit-patch
       http://jrv.oddones.org/fit-demo.tar.gz


     - Jim Van Zandt

set xtics <incr> has no effect with xtic(n)

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

shige 02/20 2009
----------------

In gnuplot-4.2 or after, I found that the command "set xtics 
<incr>" has no effect when "xticlabels(n)" is used.

For example The commands

 plot 'data' using 0:2:xtic(1) with lp

for the data

 01/03 10
 01/04 20
 01/05 15
 ....

makes labels at every x=0,1,2,... and they are overlap each other.

In the case without xtic(1), we may use "set xtics <incr>" to 
avoid it:

 set xtics 5
 plot 'data' using 0:2 with lp

This makes skipped labels at x=0,5,10,... But with xtic(1), "set 
xtics 5" has no effect:

 set xtics 5
 plot 'data' using 0:2:xtic(1) with lp

This makes labels at every x=0,1,2,... 

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

Re: png: selecting builtin font impossible?

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

On Thursday 19 February 2009 03:52:38 Manfred Schwarb wrote:
> > On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote:
> > > 
> > > > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> > > > >
> > > > > your change in term/png.trm of
> > > > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > > > > font default.
> > > > > 
> > > > > Now, I can't select the builtin fonts any more.
> > > > > I tried
> > > > > "set term png small"
> > > > > "set term png small font small"
> > > > > "set term png font small"
> > > > > 
> > > > > but I always get Arial as the selected font.
> > > > > How to select the builtin fonts?
> > > > 
> > > > Why would you ever want to?
> > > > 
> > > 
> > > 
> > > 1) Because I want to be able to shoot myself into the foot?
> > > 
> > > 2) Because I don't want blurred text in an otherwise unblurred
> > >    plot? I really want terminal-font quality in a pixel plot.
> > 
> > So why not set the font to whatever you are using in your terminal?
> > 
> 
> How to do? You can only select Truetype fonts. 

That is not correct.  libgd is not limited to TrueType fonts. 
The font handling is done via freetype2, which handles quite a 
variety of font formats:
	http://freetype.sourceforge.net/freetype2/

> E.g. I'd like to set the 
> font to the "6x13" terminal font, and something like
> "set term png font '6x13'" does not work, as expected.

On my machine such fonts are installed under the names "Terminal [Bitstream]"
and "Terminal [DEC]".  Font installation and naming varies widely, so
beyond that I cannot help much.

> > > 3) For 90 degree rotated text, font quality for non-builtin
> > >    fonts is really bad. 
> > 
> > That makes no sense to me at all.  The font rendering in libgd
> > is identical in the two cases. All that the rotation changes is the
> > order in which text pixels are copied across onto the image canvas.
> > 90-rotated text should be pixel-for-pixel identical to unrotated text.
> > If it isn't, this sounds like a bug that should be filed against libgd
> > rather than against gnuplot.
> > 
> > >    I can send examples if you like. 
> > 
> > Please do. Please also provide the script that generated them,
> > and the version number of libgd against which gnuplot is linked.
> > Probably a good idea to send them to the libgd list also.
> >
> 
> I suspect it is a generic issue (or perhaps I simply expect too much
> from font rendering machines). I tested with pngcairo, and I got the
> same artefact. It's like there is a too coarse or skewed color gradient
> when rendering the characters, I don't know.
> 
> libgd and libcairo are reasonably new, I guess (2.0.36 and 1.4.10).
> 
> I will attach some plot snipplets to this email, for builtin, ttf 
> and cairo. 

But you did not attach the generating script.
It seems clear to me from inspection of the "bad" ttf rotated text that
the rotation angle is not truly 90.  Without seeing the command that
generated this text, I cannot say why that would happen.

It is true that when you rotate text to an arbitrary angle, then the
characters become somewhat distorted.  Then again, with the builtin fonts
you cannot rotate text to arbitrary angles at all.
 
> > > 4) If you want to produce light-weight plots for e.g. web applications
> > >    (i.e. the fewer bytes the better) you really want to avoid
> > >    such truetype fonts.
> > 
> > Possibly. But I am curious about the weight of that argument.
> > Can you provide some numbers that demonstrate a significant difference
> > in the output file sizes?  If I compare the output of a 'typical' plot
> > from the demo set using "verdana,9" as compared to the "medium" built-in
> > font, I get a difference of about 400 bytes out of 8000.  I would gladly
> > pay that price, because to my eyes the built-in font is both ugly and
> > harder to read.  You have said that your eyes disagree, and I believe you.
> > On the other hand, if you are exporting your plots to the rest of the
> > world then the question is what does a typical viewer think about it?
> > I realize that discussion of font preferences can degenerate into
> > intractable differences of opinion, but you must be aware that many
> > people prefer anti-aliased text.
> > 
> 
> Size: in a plot with moderate amount of labels, I get:
> ttf -> builtin:  -15%
> ttf -> cairo:    +40%

The cairo output is a from completely different driver, and a completely
different text processing system.  You can compare it if you like, but
it is not really relevant to the choice of fonts for the png driver.

> For the attached snipplets, the size differences are much bigger.

The fonts, and the image size itself, are larger for your ttf.png example
than for your builtin.png example.  If you color more pixels, then yes the
image size is larger. But to blame a larger and heavier font for coloring
more pixels is, I think, a bit disingenuous.  On top of that, it is evident
that the rotation angle in the ttf example is not exactly 90, which
distorts the characters and causes additional rows of pixels to be colored.

Here is what I get:
    set term png font "courbd,9"
    set output 'rav_courbd.png'
    load 'running_avg.dem'
## unsetenv GDFONTPATH
    set term png medium
    set output 'rav_builtin.png'
    load 'running_avg.dem'

chauvet [21] ls -l *.png
-rw-rw-r-- 1 merritt merritt 7022 2009-02-19 12:43 rav_builtin.png
-rw-rw-r-- 1 merritt merritt 7496 2009-02-19 12:52 rav_courbd.png

So for fonts that are roughly the same style, size, and weight,
I get a difference of about 475/7500 = 6% difference in image size. 

-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

> On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote:
> > 
> > > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> > > >
> > > > your change in term/png.trm of
> > > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > > > font default.
> > > > 
> > > > Now, I can't select the builtin fonts any more.
> > > > I tried
> > > > "set term png small"
> > > > "set term png small font small"
> > > > "set term png font small"
> > > > 
> > > > but I always get Arial as the selected font.
> > > > How to select the builtin fonts?
> > > 
> > > Why would you ever want to?
> > > 
> > 
> > 
> > 1) Because I want to be able to shoot myself into the foot?
> > 
> > 2) Because I don't want blurred text in an otherwise unblurred
> >    plot? I really want terminal-font quality in a pixel plot.
> 
> So why not set the font to whatever you are using in your terminal?
> 

How to do? You can only select Truetype fonts. E.g. I'd like to set the
font to the "6x13" terminal font, and something like
"set term png font '6x13'" does not work, as expected.


> >    Otherwise I would use vector output (i.e. ps-terminal) and
> >    convert the resulting vector plot into png. This way I would
> >    get homogeneous "blurring".
> >    So for me the question is really 
> >    "Why would you ever want to NOT to?" (for a pixel terminal).
> 
> It sounds to me that you might have a font problem external to
> gnuplot per se, but I don't know what it might be.
> 
> > 3) For 90 degree rotated text, font quality for non-builtin
> >    fonts is really bad. 
> 
> That makes no sense to me at all.  The font rendering in libgd
> is identical in the two cases. All that the rotation changes is the
> order in which text pixels are copied across onto the image canvas.
> 90-rotated text should be pixel-for-pixel identical to unrotated text.
> If it isn't, this sounds like a bug that should be filed against libgd
> rather than against gnuplot.
> 
> >    I can send examples if you like. 
> 
> Please do. Please also provide the script that generated them,
> and the version number of libgd against which gnuplot is linked.
> Probably a good idea to send them to the libgd list also.
>

I suspect it is a generic issue (or perhaps I simply expect too much
from font rendering machines). I tested with pngcairo, and I got the
same artefact. It's like there is a too coarse or skewed color gradient
when rendering the characters, I don't know.

libgd and libcairo are reasonably new, I guess (2.0.36 and 1.4.10).

I will attach some plot snipplets to this email, for builtin, ttf 
and cairo. The upper strings are done with "set label" in combination
with "splot", the lower ones are plotted with "set label" in a 
"plot" plot. The upper labels seem to be of higher quality than
the lower ones, somehow.
Please ignore the bad text alignment in the plots, just look at the
characters themself.


> > 4) If you want to produce light-weight plots for e.g. web applications
> >    (i.e. the fewer bytes the better) you really want to avoid
> >    such truetype fonts.
> 
> Possibly. But I am curious about the weight of that argument.
> Can you provide some numbers that demonstrate a significant difference
> in the output file sizes?  If I compare the output of a 'typical' plot
> from the demo set using "verdana,9" as compared to the "medium" built-in
> font, I get a difference of about 400 bytes out of 8000.  I would gladly
> pay that price, because to my eyes the built-in font is both ugly and
> harder to read.  You have said that your eyes disagree, and I believe you.
> On the other hand, if you are exporting your plots to the rest of the
> world then the question is what does a typical viewer think about it?
> I realize that discussion of font preferences can degenerate into
> intractable differences of opinion, but you must be aware that many
> people prefer anti-aliased text.
> 

Size: in a plot with moderate amount of labels, I get:
ttf -> builtin:  -15%
ttf -> cairo:    +40%
For the attached snipplets, the size differences are much bigger.


> > > Font problems are the most common cause for complaint or requested
> > > support with regard to the png terminal.  Neither enhanced text nor
> > > internationalization work with the built-in fonts.  The rationale
> > > for the change you point to was to make it as hard as possible to
> > > end up with the built-in fonts.  I consider them as only a last
> > > resort to be used in desperation.
> > > 
> > 
> > Hmm, setting the default is one thing. Taking away the choice is
> > another thing. 
> 
> If you always want to use the gd built-in fonts, then it seems to
> make sense to simply remove GDFONTPATH from the environment in 
> which your web applications run.
>


Yes, this works for me.


Thanks,
Manfred


> 
> 
>  
> > Cheers,
> > Manfred
> > 
> > 
> > 
> > > Having said that, I would think you could defeat the search for
> > > arial.ttf by clearing the GDFONTPATH environmental variable.
> > > And you can certainly set the default font to something other than
> > > arial.  For example, if you want a mono-spaced font you could set
> > > GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> > > or couri (ttf equivalent).
> > > 
> > > -- 
> > > Ethan A Merritt
> 
> 
> 
> -- 
> Ethan A Merritt

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Build breakage with "-DDEBUG"

[Manfred S. <man...@gm...>]

Hi,

I tried to compile gnuplot with "gcc -DDEBUG", and got the following abort:

gpexecute.o: In function `gp_exec_event':
src/gpexecute.c:229: undefined reference to `gp_execute'


Something like this is probably needed:

--- gpexecute.c.orig    2009-02-19 11:12:06.000000000 +0100
+++ gpexecute.c 2009-02-19 11:30:45.000000000 +0100
@@ -223,11 +223,11 @@
     static struct gpe_fifo_t *base = (gpe_fifo_t *) 0;
 #endif

-#ifdef DEBUG
+#if defined(DEBUG) && defined(OS2_IPC)
     char s[127];
     sprintf(s, "%%%c %d %d %d %d %d", type, mx, my, par1, par2, winid);
     gp_execute(s);
-#endif /* DEBUG */
+#endif /* DEBUG && OS2_IPC */

     ge.type = type;
     ge.mx = mx;



Cheers,
Manfred

Re: segfault in plot3d

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

Daniel J Sebald wrote:

> I'd say though that the hunk of code as it existed (exists) wasn't as
> clean as it could have been.  For example, the addition of this line:

Ethan,

Give this patch a try.  I cleans up the loop and groups iteration earlier the way it is grouped inside the loop.  As for the "Fixme" question, I do think recording the iteration is necessary.

All demos still pass after this patch is applied.

Dan

Re: segfault in plot3d

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

Ethan A Merritt wrote:
> On Tuesday 17 February 2009, James R. Van Zandt wrote:
> 
>>I ran across a reliable segfault with the splot command, with the
>>current CVS code:
> 
> 
> There is now a fix for this problem in CVS.
> 
> 	Ethan

I see now.  The fix works.

I'd say though that the hunk of code as it existed (exists) wasn't as clean as it could have been.  For example, the addition of this line:

@@ -1743,6 +1743,7 @@

                    this_plot->plot_type = DATA3D;
                    this_plot->plot_style = this_style;
+                   this_plot->iteration = iteration;
                    /* Struct copy */
                    this_plot->lp_properties = *these_props;

likely isn't needed because next time through the loop "this_plot->iteration = iteration" is done higher up in the while do/while loop.  (Global "iteration" is modified by the parse.c code, none of which is called here so global "iteration" should not change in between the two assignments.)

In fact, the "while (df_return != DF_EOF)" won't have a chance to fail because higher in the loop is a break statement

		    if (df_return == DF_EOF)
			break;

Going a little higher up in the loop is

		do {
		    this_plot = *tp_3d_ptr;

but this is extraneous because notice a few lines before this is

	    assert(this_plot == *tp_3d_ptr);

and at the bottom of the loop is

		    if ((this_plot = *tp_3d_ptr) != NULL) {
			if (this_plot->title) {
			    free(this_plot->title);
			    this_plot->title = NULL;
			}
		    } else {
			/* Allocate enough isosamples and samples */
			this_plot = *tp_3d_ptr = sp_alloc(0, 0, 0, 0);
		    }

so it is certain that "this_plot == *tp_3d_ptr".

Dan

Re: segfault in plot3d

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

On Tuesday 17 February 2009, James R. Van Zandt wrote:
> 
> I ran across a reliable segfault with the splot command, with the
> current CVS code:

There is now a fix for this problem in CVS.

	Ethan



> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified February 2009
> 
> In particular, this is *without* my proposed changes to fit.c
> 
> Here's a run under the debugger:
> 
> gnuplot> splot 'lin2.dat',x+y
> [New Thread 0xb7843a40 (LWP 27810)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7843a40 (LWP 27810)]
> calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> (gdb) backtrace
> #0  calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> #1  0x080a808c in plot3drequest () at plot3d.c:1909
> #2  0x080571d7 in do_line () at command.c:595
> #3  0x0805796d in com_line () at command.c:338
> #4  0x0809a6dd in main (argc=1, argv=0xbffb35a4) at plot.c:659
> (gdb) 
> 
> Here's lin2.dat:
> ---------------------------------------------
> #octave:9> for x=[1:4];for y=[2:5]; fprintf('%f %f %f 1\n',x,y,10*x+2*y+randn);end;end
> 1.000000 2.000000 13.753875 1
> 1.000000 3.000000 15.843192 1
> 1.000000 4.000000 17.752269 1
> 1.000000 5.000000 18.819627 1
> 
> 
> 2.000000 2.000000 25.480149 1
> 2.000000 3.000000 26.217588 1
> 2.000000 4.000000 28.555638 1
> 2.000000 5.000000 30.757950 1
> 
> 
> 3.000000 2.000000 33.879955 1
> 3.000000 3.000000 36.190724 1
> 3.000000 4.000000 39.199289 1
> 3.000000 5.000000 40.153219 1
> 
> 
> 4.000000 2.000000 43.413695 1
> 4.000000 3.000000 45.938903 1
> 4.000000 4.000000 49.196757 1
> 4.000000 5.000000 50.136290 1
> #octave:10> diary off
> -----------------------------------------
> 
> 
> All these commands work fine:
> 
>    gnuplot> splot 'fit2.dat'
>    gnuplot> splot x+y
>    gnuplot> splot x+y,'fit2.dat'
> 
> It only fails when plotting the data file first, then the function.
> I've had other data files fail, but demo/glasses.dat succeeds.
> 
> I set a breakpoint at plot3d.c:1174 in calculate_set_of_isolines() and
> followed execution.  When j=0 and i=99, the function reaches end of
> the linked list, sets this_iso to zero, then sets points to zero.  The
> next time through when j=1 and i=0, the function dies trying to access
> points[i].x.  I haven't been able to identify the cause.
> 
> I have a couple of other binaries installed.
> This version also crashes:
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified January 2007
> 
> This version is okay:
>         G N U P L O T
>         Version 4.2 patchlevel 4 
>         last modified Sep 2008
> 
> 
> Does anyone else see this?
> 
>      - Jim Van Zandt
> 


-- 
Ethan A Merritt

Re: segfault in plot3d

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

On Wednesday 18 February 2009, Daniel J Sebald wrote:
> James R. Van Zandt wrote:
> 
> > Daniel J Sebald <dan...@ie...> wrote:
> > 
> >>That explains it.  The double line break means to start another 3D
> >>curve.  (A single break means to start another trace of the 3D curve.)
> >>So Jim's example is attempting a 3D plot with single dimensioned data.
> > 
> > 
> > I don't follow what you mean by "single dimensioned data".  Each point
> > has an X, Y, and Z value.  With "set style data lines", the points are
> > connected along only one dimension, which is fine with me.  Actually I
> > was using the default style, so I got only the points.
> > 
> > 
> >>Either a check should be put in plot3d.c, or a datafile [like this]
> >>should be disallowed...
> > 
> > 
> > I see no reason to disallow it.  It used to work.  And it still works
> > unless you plot data after a function.  (Succeeds by accident?)
> 
> Good chance, would be my guess.  Someone disallowed the number of samples in a dimension to be 1.
> 
> 
> > The docs say
> > 
> > "If all datablocks contain the same number of points, gnuplot will
> > draw cross-isolines between datablocks, connecting corresponding
> > points."
> > 
> > Apparently gnuplot should check that there is more than one datablock
> > before attempting to draw cross-isolines.
> 
> Yes.
> 
> Philosophically, I'm not opposed to having a single line of data appear in a 3D plot.  It's probably the case that 3D plotting functions expect (i.e., assume, or, were never tested) there to be some type of grid.
> 

You're over-thinking this.  There is nothing to stop you from plotting a series
of points in 3D that have nothing to do with a surface.  The problem data file
happens to contain 4 sets of such points.  If you split it into four separate
files, it works as expected
   splot 'line1', 'line2', 'line3', 'line4', x+y

What has gone wrong (I eventually realized) is that the code added for iteration
assumes that if you generated multiple curves from the same input file it is
_because of iteration_, whereas in this case it is simply because the input file
contains more than one curve.  I will fix that.


-- 
Ethan A Merritt

Re: segfault in plot3d

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

James R. Van Zandt wrote:

> Daniel J Sebald <dan...@ie...> wrote:
> 
>>That explains it.  The double line break means to start another 3D
>>curve.  (A single break means to start another trace of the 3D curve.)
>>So Jim's example is attempting a 3D plot with single dimensioned data.
> 
> 
> I don't follow what you mean by "single dimensioned data".  Each point
> has an X, Y, and Z value.  With "set style data lines", the points are
> connected along only one dimension, which is fine with me.  Actually I
> was using the default style, so I got only the points.
> 
> 
>>Either a check should be put in plot3d.c, or a datafile [like this]
>>should be disallowed...
> 
> 
> I see no reason to disallow it.  It used to work.  And it still works
> unless you plot data after a function.  (Succeeds by accident?)

Good chance, would be my guess.  Someone disallowed the number of samples in a dimension to be 1.


> The docs say
> 
> "If all datablocks contain the same number of points, gnuplot will
> draw cross-isolines between datablocks, connecting corresponding
> points."
> 
> Apparently gnuplot should check that there is more than one datablock
> before attempting to draw cross-isolines.

Yes.

Philosophically, I'm not opposed to having a single line of data appear in a 3D plot.  It's probably the case that 3D plotting functions expect (i.e., assume, or, were never tested) there to be some type of grid.

Dan

Re: segfault in plot3d

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

On Wednesday 18 February 2009 09:36:12 James R. Van Zandt wrote:
> 
> Ethan A Merritt <merritt@u.washington.edu> writes:
> >Why does your data file have two blank lines between each set of points?
> >
> >If you reduce that to a single blank line then there is no segfault.
> >Of course, it should not segfault in any case, but I'm wondering if
> >this is why no one has reported the problem before.
> 
> I used two blank lines so I could use "index" specs to select portions
> of the data file for plotting, or more usefully, for fitting.

That's fine.  I was just wondering if there was a quick work-around available.

I have figured out why the iteration tracking is interfering with the
multiple-data-sets-per-file case, but still have to think about how best
to fix it.



> 
> From: Daniel J Sebald <dan...@ie...>
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020
> X-Accept-Language: en-us, en
> MIME-Version: 1.0
> To: Ethan A Merritt <merritt@u.washington.edu>
> CC:  gnu...@li..., 
>  "James R. Van Zandt" <jr...@co...>
> Subject: Re: segfault in plot3d
> References: <E1L...@va...> <200902172152.08953.merritt@u.washington.edu>
> In-Reply-To: <200902172152.08953.merritt@u.washington.edu>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
> X-AntiAbuse: Primary Hostname - deneb.hostpapa.com
> X-AntiAbuse: Original Domain - comcast.net
> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
> X-AntiAbuse: Sender Address Domain - ieee.org
> X-Source: 
> X-Source-Args: 
> X-Source-Dir: 
> 
> Ethan A Merritt wrote:
> 
> >>gnuplot> splot 'lin2.dat',x+y
> > 
> > 
> > Why does your data file have two blank lines between each set of points?
> > 
> > If you reduce that to a single blank line then there is no segfault.
> > Of course, it should not segfault in any case, but I'm wondering if
> > this is why no one has reported the problem before.
> 
> Daniel J Sebald <dan...@ie...> wrote:
> > That explains it.  The double line break means to start another 3D
> > curve.  (A single break means to start another trace of the 3D curve.)
> > So Jim's example is attempting a 3D plot with single dimensioned data.
> 
> I don't follow what you mean by "single dimensioned data".  Each point
> has an X, Y, and Z value.  With "set style data lines", the points are
> connected along only one dimension, which is fine with me.  Actually I
> was using the default style, so I got only the points.
> 
> > Either a check should be put in plot3d.c, or a datafile [like this]
> > should be disallowed...
> 
> I see no reason to disallow it.  It used to work.  And it still works
> unless you plot data after a function.  (Succeeds by accident?)  
> 
> The docs say
> 
> "If all datablocks contain the same number of points, gnuplot will
> draw cross-isolines between datablocks, connecting corresponding
> points."
> 
> Apparently gnuplot should check that there is more than one datablock
> before attempting to draw cross-isolines.
> 
>           - Jim Van Zandt
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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: png: selecting builtin font impossible?

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

On Wednesday 18 February 2009 09:41:44 Manfred Schwarb wrote:
> 
> > On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> > >
> > > your change in term/png.trm of
> > > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > > font default.
> > > 
> > > Now, I can't select the builtin fonts any more.
> > > I tried
> > > "set term png small"
> > > "set term png small font small"
> > > "set term png font small"
> > > 
> > > but I always get Arial as the selected font.
> > > How to select the builtin fonts?
> > 
> > Why would you ever want to?
> > 
> 
> 
> 1) Because I want to be able to shoot myself into the foot?
> 
> 2) Because I don't want blurred text in an otherwise unblurred
>    plot? I really want terminal-font quality in a pixel plot.

So why not set the font to whatever you are using in your terminal?

>    Otherwise I would use vector output (i.e. ps-terminal) and
>    convert the resulting vector plot into png. This way I would
>    get homogeneous "blurring".
>    So for me the question is really 
>    "Why would you ever want to NOT to?" (for a pixel terminal).

It sounds to me that you might have a font problem external to
gnuplot per se, but I don't know what it might be.

> 3) For 90 degree rotated text, font quality for non-builtin
>    fonts is really bad. 

That makes no sense to me at all.  The font rendering in libgd
is identical in the two cases. All that the rotation changes is the
order in which text pixels are copied across onto the image canvas.
90-rotated text should be pixel-for-pixel identical to unrotated text.
If it isn't, this sounds like a bug that should be filed against libgd
rather than against gnuplot.

>    I can send examples if you like. 

Please do. Please also provide the script that generated them,
and the version number of libgd against which gnuplot is linked.
Probably a good idea to send them to the libgd list also.
 
> 4) If you want to produce light-weight plots for e.g. web applications
>    (i.e. the fewer bytes the better) you really want to avoid
>    such truetype fonts.

Possibly. But I am curious about the weight of that argument.
Can you provide some numbers that demonstrate a significant difference
in the output file sizes?  If I compare the output of a 'typical' plot
from the demo set using "verdana,9" as compared to the "medium" built-in
font, I get a difference of about 400 bytes out of 8000.  I would gladly
pay that price, because to my eyes the built-in font is both ugly and
harder to read.  You have said that your eyes disagree, and I believe you.
On the other hand, if you are exporting your plots to the rest of the
world then the question is what does a typical viewer think about it?
I realize that discussion of font preferences can degenerate into
intractable differences of opinion, but you must be aware that many
people prefer anti-aliased text.

> > Font problems are the most common cause for complaint or requested
> > support with regard to the png terminal.  Neither enhanced text nor
> > internationalization work with the built-in fonts.  The rationale
> > for the change you point to was to make it as hard as possible to
> > end up with the built-in fonts.  I consider them as only a last
> > resort to be used in desperation.
> > 
> 
> Hmm, setting the default is one thing. Taking away the choice is
> another thing. 

If you always want to use the gd built-in fonts, then it seems to
make sense to simply remove GDFONTPATH from the environment in 
which your web applications run.



 
> Cheers,
> Manfred
> 
> 
> 
> > Having said that, I would think you could defeat the search for
> > arial.ttf by clearing the GDFONTPATH environmental variable.
> > And you can certainly set the default font to something other than
> > arial.  For example, if you want a mono-spaced font you could set
> > GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> > or couri (ttf equivalent).
> > 
> > -- 
> > Ethan A Merritt



-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

> On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
> >
> > your change in term/png.trm of
> > "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> > font default.
> > 
> > Now, I can't select the builtin fonts any more.
> > I tried
> > "set term png small"
> > "set term png small font small"
> > "set term png font small"
> > 
> > but I always get Arial as the selected font.
> > How to select the builtin fonts?
> 
> Why would you ever want to?
> 


1) Because I want to be able to shoot myself into the foot?

2) Because I don't want blurred text in an otherwise unblurred
   plot? I really want terminal-font quality in a pixel plot.
   Otherwise I would use vector output (i.e. ps-terminal) and
   convert the resulting vector plot into png. This way I would
   get homogeneous "blurring".
   So for me the question is really 
   "Why would you ever want to NOT to?" (for a pixel terminal).

3) For 90 degree rotated text, font quality for non-builtin
   fonts is really bad. I can send examples if you like.

4) If you want to produce light-weight plots for e.g. web applications
   (i.e. the fewer bytes the better) you really want to avoid
   such truetype fonts.

> Font problems are the most common cause for complaint or requested
> support with regard to the png terminal.  Neither enhanced text nor
> internationalization work with the built-in fonts.  The rationale
> for the change you point to was to make it as hard as possible to
> end up with the built-in fonts.  I consider them as only a last
> resort to be used in desperation.
> 

Hmm, setting the default is one thing. Taking away the choice is
another thing. 

Cheers,
Manfred



> Having said that, I would think you could defeat the search for
> arial.ttf by clearing the GDFONTPATH environmental variable.
> And you can certainly set the default font to something other than
> arial.  For example, if you want a mono-spaced font you could set
> GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
> or couri (ttf equivalent).
> 
> -- 
> Ethan A Merritt

-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: segfault in plot3d

[James R. V. Z. <jr...@co...>]

Ethan A Merritt <merritt@u.washington.edu> writes:
>Why does your data file have two blank lines between each set of points?
>
>If you reduce that to a single blank line then there is no segfault.
>Of course, it should not segfault in any case, but I'm wondering if
>this is why no one has reported the problem before.

I used two blank lines so I could use "index" specs to select portions
of the data file for plotting, or more usefully, for fitting.

From: Daniel J Sebald <dan...@ie...>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ethan A Merritt <merritt@u.washington.edu>
CC:  gnu...@li..., 
 "James R. Van Zandt" <jr...@co...>
Subject: Re: segfault in plot3d
References: <E1L...@va...> <200902172152.08953.merritt@u.washington.edu>
In-Reply-To: <200902172152.08953.merritt@u.washington.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - deneb.hostpapa.com
X-AntiAbuse: Original Domain - comcast.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieee.org
X-Source: 
X-Source-Args: 
X-Source-Dir: 

Ethan A Merritt wrote:

>>gnuplot> splot 'lin2.dat',x+y
> 
> 
> Why does your data file have two blank lines between each set of points?
> 
> If you reduce that to a single blank line then there is no segfault.
> Of course, it should not segfault in any case, but I'm wondering if
> this is why no one has reported the problem before.

Daniel J Sebald <dan...@ie...> wrote:
> That explains it.  The double line break means to start another 3D
> curve.  (A single break means to start another trace of the 3D curve.)
> So Jim's example is attempting a 3D plot with single dimensioned data.

I don't follow what you mean by "single dimensioned data".  Each point
has an X, Y, and Z value.  With "set style data lines", the points are
connected along only one dimension, which is fine with me.  Actually I
was using the default style, so I got only the points.

> Either a check should be put in plot3d.c, or a datafile [like this]
> should be disallowed...

I see no reason to disallow it.  It used to work.  And it still works
unless you plot data after a function.  (Succeeds by accident?)  

The docs say

"If all datablocks contain the same number of points, gnuplot will
draw cross-isolines between datablocks, connecting corresponding
points."

Apparently gnuplot should check that there is more than one datablock
before attempting to draw cross-isolines.

          - Jim Van Zandt

Re: png: selecting builtin font impossible?

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

On Wednesday 18 February 2009 05:13:09 Manfred Schwarb wrote:
>
> your change in term/png.trm of
> "revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
> font default.
> 
> Now, I can't select the builtin fonts any more.
> I tried
> "set term png small"
> "set term png small font small"
> "set term png font small"
> 
> but I always get Arial as the selected font.
> How to select the builtin fonts?

Why would you ever want to?

Font problems are the most common cause for complaint or requested
support with regard to the png terminal.  Neither enhanced text nor
internationalization work with the built-in fonts.  The rationale
for the change you point to was to make it as hard as possible to
end up with the built-in fonts.  I consider them as only a last
resort to be used in desperation.

Having said that, I would think you could defeat the search for
arial.ttf by clearing the GDFONTPATH environmental variable.
And you can certainly set the default font to something other than
arial.  For example, if you want a mono-spaced font you could set
GNUPLOT_DEFAULT_GDFONT to Courier (postscript font)
or couri (ttf equivalent).

-- 
Ethan A Merritt

Re: png: selecting builtin font impossible?

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

> Now, I can't select the builtin fonts any more.
> I tried
> "set term png small"
> "set term png small font small"
> "set term png font small"
> 
> but I always get Arial as the selected font.
> How to select the builtin fonts?

I see this also ... trying

	GDFONTPATH=. gnuplot
or
	GDFONTPATH=/dev/null gnuplot

I get:

gnuplot> set term png tiny; show term; set out '0tiny.png'; test
   terminal type is png nocrop tiny size 640,480
Could not find/open font when opening font "arial", using internal 
non-scalable font

However, the output for tiny, small, giant, ... is correct.

---
PM

png: selecting builtin font impossible?

[Manfred S. <man...@gm...>]

Ethan,

your change in term/png.trm of
"revision 1.130, Thu Nov 20 06:14:41 2008 UTC" set "arial" as the
font default.

Now, I can't select the builtin fonts any more.
I tried
"set term png small"
"set term png small font small"
"set term png font small"

but I always get Arial as the selected font.
How to select the builtin fonts?

Thanks,
Manfred


-- 
Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Re: segfault in plot3d

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

Ethan A Merritt wrote:

>>gnuplot> splot 'lin2.dat',x+y
> 
> 
> Why does your data file have two blank lines between each set of points?
> 
> If you reduce that to a single blank line then there is no segfault.
> Of course, it should not segfault in any case, but I'm wondering if
> this is why no one has reported the problem before.

That explains it.  The double line break means to start another 3D curve.  (A single break means to start another trace of the 3D curve.)  So Jim's example is attempting a 3D plot with single dimensioned data.

I tried doing such a thing with functions rather than data, but notice that

gnuplot> set samples 100, 1
                           ^
         sampling rate must be > 1; sampling unchanged

prevents one from even doing so.  Either a check should be put in plot3d.c, or a datafile should be disallowed similar to the above gnuplot error message.

Dan

Re: segfault in plot3d

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

On Tuesday 17 February 2009, James R. Van Zandt wrote:
> 
> I ran across a reliable segfault with the splot command, with the
> current CVS code:
> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified February 2009
> 
> In particular, this is *without* my proposed changes to fit.c
> 
> Here's a run under the debugger:
> 
> gnuplot> splot 'lin2.dat',x+y

Why does your data file have two blank lines between each set of points?

If you reduce that to a single blank line then there is no segfault.
Of course, it should not segfault in any case, but I'm wondering if
this is why no one has reported the problem before.

	Ethan



> [New Thread 0xb7843a40 (LWP 27810)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7843a40 (LWP 27810)]
> calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> (gdb) backtrace
> #0  calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> #1  0x080a808c in plot3drequest () at plot3d.c:1909
> #2  0x080571d7 in do_line () at command.c:595
> #3  0x0805796d in com_line () at command.c:338
> #4  0x0809a6dd in main (argc=1, argv=0xbffb35a4) at plot.c:659
> (gdb) 
> 
> Here's lin2.dat:
> ---------------------------------------------
> #octave:9> for x=[1:4];for y=[2:5]; fprintf('%f %f %f 1\n',x,y,10*x+2*y+randn);end;end
> 1.000000 2.000000 13.753875 1
> 1.000000 3.000000 15.843192 1
> 1.000000 4.000000 17.752269 1
> 1.000000 5.000000 18.819627 1
> 
> 
> 2.000000 2.000000 25.480149 1
> 2.000000 3.000000 26.217588 1
> 2.000000 4.000000 28.555638 1
> 2.000000 5.000000 30.757950 1
> 
> 
> 3.000000 2.000000 33.879955 1
> 3.000000 3.000000 36.190724 1
> 3.000000 4.000000 39.199289 1
> 3.000000 5.000000 40.153219 1
> 
> 
> 4.000000 2.000000 43.413695 1
> 4.000000 3.000000 45.938903 1
> 4.000000 4.000000 49.196757 1
> 4.000000 5.000000 50.136290 1
> #octave:10> diary off
> -----------------------------------------
> 
> 
> All these commands work fine:
> 
>    gnuplot> splot 'fit2.dat'
>    gnuplot> splot x+y
>    gnuplot> splot x+y,'fit2.dat'
> 
> It only fails when plotting the data file first, then the function.
> I've had other data files fail, but demo/glasses.dat succeeds.
> 
> I set a breakpoint at plot3d.c:1174 in calculate_set_of_isolines() and
> followed execution.  When j=0 and i=99, the function reaches end of
> the linked list, sets this_iso to zero, then sets points to zero.  The
> next time through when j=1 and i=0, the function dies trying to access
> points[i].x.  I haven't been able to identify the cause.
> 
> I have a couple of other binaries installed.
> This version also crashes:
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified January 2007
> 
> This version is okay:
>         G N U P L O T
>         Version 4.2 patchlevel 4 
>         last modified Sep 2008
> 
> 
> Does anyone else see this?
> 
>      - Jim Van Zandt
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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: segfault in plot3d

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

On Tuesday 17 February 2009, James R. Van Zandt wrote:
> 
> I ran across a reliable segfault with the splot command, with the
> current CVS code:
> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified February 2009

I can reproduce the bug.
I bisected it back to a single patch to plot3d on 20-Oct-2006.
The patch added support for iteration.  

http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/plot3d.c?r1=1.132&r2=1.133&view=patch

And there I lose it.  I can't see what that check for iteration has to do with this crash.
There is no iteration in the command that triggers the crash, so the iteration
code should not do anything at all.  Yet reverting that one set of checks makes the
crash go away.

Can anyone else see what is going on?

	Ethan


 
> In particular, this is *without* my proposed changes to fit.c
> 
> Here's a run under the debugger:
> 
> gnuplot> splot 'lin2.dat',x+y
> [New Thread 0xb7843a40 (LWP 27810)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7843a40 (LWP 27810)]
> calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> (gdb) backtrace
> #0  calculate_set_of_isolines (value_axis=FIRST_Z_AXIS, cross=false, this_iso=0xbffb32e0, iso_axis=FIRST_Y_AXIS, iso_min=2, iso_step=0.33333333333333331, num_iso_to_use=10, sam_axis=FIRST_X_AXIS, sam_min=1, sam_step=0.030303030303030304, num_sam_to_use=100, need_palette=false) at plot3d.c:1174
> #1  0x080a808c in plot3drequest () at plot3d.c:1909
> #2  0x080571d7 in do_line () at command.c:595
> #3  0x0805796d in com_line () at command.c:338
> #4  0x0809a6dd in main (argc=1, argv=0xbffb35a4) at plot.c:659
> (gdb) 
> 
> Here's lin2.dat:
> ---------------------------------------------
> #octave:9> for x=[1:4];for y=[2:5]; fprintf('%f %f %f 1\n',x,y,10*x+2*y+randn);end;end
> 1.000000 2.000000 13.753875 1
> 1.000000 3.000000 15.843192 1
> 1.000000 4.000000 17.752269 1
> 1.000000 5.000000 18.819627 1
> 
> 
> 2.000000 2.000000 25.480149 1
> 2.000000 3.000000 26.217588 1
> 2.000000 4.000000 28.555638 1
> 2.000000 5.000000 30.757950 1
> 
> 
> 3.000000 2.000000 33.879955 1
> 3.000000 3.000000 36.190724 1
> 3.000000 4.000000 39.199289 1
> 3.000000 5.000000 40.153219 1
> 
> 
> 4.000000 2.000000 43.413695 1
> 4.000000 3.000000 45.938903 1
> 4.000000 4.000000 49.196757 1
> 4.000000 5.000000 50.136290 1
> #octave:10> diary off
> -----------------------------------------
> 
> 
> All these commands work fine:
> 
>    gnuplot> splot 'fit2.dat'
>    gnuplot> splot x+y
>    gnuplot> splot x+y,'fit2.dat'
> 
> It only fails when plotting the data file first, then the function.
> I've had other data files fail, but demo/glasses.dat succeeds.
> 
> I set a breakpoint at plot3d.c:1174 in calculate_set_of_isolines() and
> followed execution.  When j=0 and i=99, the function reaches end of
> the linked list, sets this_iso to zero, then sets points to zero.  The
> next time through when j=1 and i=0, the function dies trying to access
> points[i].x.  I haven't been able to identify the cause.
> 
> I have a couple of other binaries installed.
> This version also crashes:
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified January 2007
> 
> This version is okay:
>         G N U P L O T
>         Version 4.2 patchlevel 4 
>         last modified Sep 2008
> 
> 
> Does anyone else see this?
> 
>      - Jim Van Zandt
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> 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