gnuplot-beta Mailing List for gnuplot (Page 36)

On Sun, 6 May 2018, Erik Luijten wrote:

> Hello,
>
> Here is an alternative version of Gnuplot 5.2.3 compiled for OS X:
>
> https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
>
> It includes the GNU readline functionality and also has the PDF terminal
> (which, even though deprecated, works very well and is widely used).

For anyone who's "shopping" for gnuplot on OS X I might mention a 
couple of other differences between the Erik's builds and mine: mine 
do not require X11/XQuartz (they include the aqua and wxt interactive 
terminals but not x11), and they are compatible with OS X 10.6.6 and 
higher.

Erik mentions that his builds were made on 10.11.6; I don't know what 
the minimum compatible OS X version is.

Allin Cottrell

Hello,

Here is an alternative version of Gnuplot 5.2.3 compiled for OS X:

https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X

It includes the GNU readline functionality and also has the PDF terminal
(which, even though deprecated, works very well and is widely used).

Regards,

Erik Luijten

There's now a build of gnuplot 5.2.3 for Mac OS X at
http://ricardo.ecn.wfu.edu/pub/gnuplot/

It's available in both pkg and dmg form.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

I have uploaded windows binary packages on the 5.2.3 on File tag on the SourceForge.

I included renamed fontconfig utilities (e.g. fc-cache-gp)  in bin directory.

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA 
> To: Merritt Ethan ; gnuplot-beta
> Cc: 
> Date: 2018/5/6, Sun 07:17
> Subject: Re: Release 5.2.3
> 
> Sorry for the noise.
> 
> Perhaps I mis-operate 7zip FileManger for extracting tar.gz.
> 
> I re-operate and build is now going.
> 
> Thanks.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam 
>>  To: gnuplot-beta Tatsuro MATSUOKA 
>>  Cc: 
>>  Date: 2018/5/6, Sun 00:49
>>  Subject: Re: Release 5.2.3
>> 
>>  On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
>>>   I cannot build the source of 5.2.3 (that could be build on testing).
>>> 
>>>   gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
>>  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> 
>>  -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows 
> -DHAVE_CONFIG_H 
>>  -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
>>  -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
>>  -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
>>  Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
>>  -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
>>  -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
>>  -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP 
> -DREADLINE  
>>  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
>>>   In file included from ../../src/eval.h:43:0,
>>>                    from ../../src/eval.c:41:
>>>   ../../src/gp_types.h:188:5: error: unknown type name 
> 'coordval'
>>>        coordval x, y, z;
>>>        ^~~~~~~~
>>>   ../../src/gp_types.h:189:5: error: unknown type name 
> 'coordval'
>>>        coordval ylow, yhigh; /* ignored in 3d */
>>>        ^~~~~~~~
>>>    many errors
>> 
>>  Have you checked the md5sum after downloading?
>>  Maybe there was file corruption.
>> 
>>>   This might happen due to fixes after testing and 5.2.3.
>> 
>>  The only changes to source files between the testing version 
>>  and the release are these:
>> 
>>  diff --git a/term/post.trm b/term/post.trm
>>  index 25efcd8..e1628af 100644
>>  --- a/term/post.trm
>>  +++ b/term/post.trm
>>  @@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, 
> int 
>>  y0, int dx, int
>>  dy));
>>  static void PS_dump_header_to_file __PROTO((char *name));
>>  #endif
>> 
>>  -static float ps_fontsize;
>>  -static float ps_fontsize_previous;
>>  +static float ps_fontsize = 14.;
>>  +static float ps_fontsize_previous = 0.;
>> 
>>  /* for enhanced mode, we keep a separate font name and size, which
>>    * is restored to the default value on font of ""
>>  -- 
>>  diff --git a/src/version.c b/src/version.c
>>  index 476efe3..6cbbe8c 100644
>>  --- a/src/version.c
>>  +++ b/src/version.c
>>  @@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
>>  #ifdef DEVELOPMENT_VERSION
>>  #include "timestamp.h"
>>  #else
>>  -const char gnuplot_date[] = "2018-04-21 ";
>>  +const char gnuplot_date[] = "2018-05-04 ";
>>  #endif
>>  const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
> 
>>  2007-2018";
>> 
>>  -- 
>> 
>>      Ethan
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Sorry for the noise.

Perhaps I mis-operate 7zip FileManger for extracting tar.gz.

I re-operate and build is now going.

Thanks.

Tatsuro



----- Original Message -----
> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA 
> Cc: 
> Date: 2018/5/6, Sun 00:49
> Subject: Re: Release 5.2.3
> 
> On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
>>  I cannot build the source of 5.2.3 (that could be build on testing).
>> 
>>  gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
> -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H 
> -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
> -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
> -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
> Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
> -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
> -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
> -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  
> -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
>>  In file included from ../../src/eval.h:43:0,
>>                   from ../../src/eval.c:41:
>>  ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>>       coordval x, y, z;
>>       ^~~~~~~~
>>  ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>>       coordval ylow, yhigh; /* ignored in 3d */
>>       ^~~~~~~~
>>   many errors
> 
> Have you checked the md5sum after downloading?
> Maybe there was file corruption.
> 
>>  This might happen due to fixes after testing and 5.2.3.
> 
> The only changes to source files between the testing version 
> and the release are these:
> 
> diff --git a/term/post.trm b/term/post.trm
> index 25efcd8..e1628af 100644
> --- a/term/post.trm
> +++ b/term/post.trm
> @@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, int 
> y0, int dx, int
> dy));
> static void PS_dump_header_to_file __PROTO((char *name));
> #endif
> 
> -static float ps_fontsize;
> -static float ps_fontsize_previous;
> +static float ps_fontsize = 14.;
> +static float ps_fontsize_previous = 0.;
> 
> /* for enhanced mode, we keep a separate font name and size, which
>   * is restored to the default value on font of ""
> -- 
> diff --git a/src/version.c b/src/version.c
> index 476efe3..6cbbe8c 100644
> --- a/src/version.c
> +++ b/src/version.c
> @@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
> #ifdef DEVELOPMENT_VERSION
> #include "timestamp.h"
> #else
> -const char gnuplot_date[] = "2018-04-21 ";
> +const char gnuplot_date[] = "2018-05-04 ";
> #endif
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
> 2007-2018";
> 
> -- 
> 
>     Ethan
> 

On Saturday, 05 May 2018 18:41:12 Tatsuro MATSUOKA wrote:
> I cannot build the source of 5.2.3 (that could be build on testing).
> 
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors

Have you checked the md5sum after downloading?
Maybe there was file corruption.

> This might happen due to fixes after testing and 5.2.3.

The only changes to source files between the testing version 
and the release are these:

diff --git a/term/post.trm b/term/post.trm
index 25efcd8..e1628af 100644
--- a/term/post.trm
+++ b/term/post.trm
@@ -270,8 +270,8 @@ static void PS_skip_image __PROTO((int bytes, int x0, int y0, int dx, int
 dy));
 static void PS_dump_header_to_file __PROTO((char *name));
 #endif
 
-static float ps_fontsize;
-static float ps_fontsize_previous;
+static float ps_fontsize = 14.;
+static float ps_fontsize_previous = 0.;
 
 /* for enhanced mode, we keep a separate font name and size, which
  * is restored to the default value on font of ""
-- 
diff --git a/src/version.c b/src/version.c
index 476efe3..6cbbe8c 100644
--- a/src/version.c
+++ b/src/version.c
@@ -40,7 +40,7 @@ const char gnuplot_patchlevel[] = "3";
 #ifdef DEVELOPMENT_VERSION
 #include "timestamp.h"
 #else
-const char gnuplot_date[] = "2018-04-21 ";
+const char gnuplot_date[] = "2018-05-04 ";
 #endif
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 2007-2018";
 
-- 

	Ethan

On Sat, May 5, 2018 at 5:41 AM, Tatsuro MATSUOKA <tma...@ya...> wrote:
> I cannot build the source of 5.2.3 (that could be build on testing).
>
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors

I'm not seeing this problem, cross-building gnuplot 5.2.3 with mingw64
on Linux. And it seems
surprising: gp_types.h includes syscfg.h at the top, and syscfg.h
contains, unconditionally,

typedef double coordval;

Allin Cottrell

Ah I forgot to mention build platform.

Native windows Msys2 + mingw w64 (gcc 7.1.0)

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Merritt Ethan <sf...@us...>; gnu...@li...
> Cc: 
> Date: 2018/5/5, Sat 18:41
> Subject: Re: Release 5.2.3
> 
> I cannot build the source of 5.2.3 (that could be build on testing).
> 
> gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  
> -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE 
> -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H 
> -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 
> -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC 
> -I/c/Program\ Files\ \(x86\)/HTML\ Help\ 
> Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H 
> -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG 
> -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF 
> -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  
> -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
> In file included from ../../src/eval.h:43:0,
>                  from ../../src/eval.c:41:
> ../../src/gp_types.h:188:5: error: unknown type name 'coordval'
>      coordval x, y, z;
>      ^~~~~~~~
> ../../src/gp_types.h:189:5: error: unknown type name 'coordval'
>      coordval ylow, yhigh; /* ignored in 3d */
>      ^~~~~~~~
>  many errors
> 
> This might happen due to fixes after testing and 5.2.3.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam via gnuplot-beta 
>>  To: gnuplot-beta
>>  Cc: 
>>  Date: 2018/5/5, Sat 13:54
>>  Subject: Release 5.2.3
>> 
>>  Source tarball for gnuplot 5.2.3 uploaded to SourceForge.
>> 
>>  One trivial fix to initialization of postscript terminal added since
>>  last week's 5.2.3-testing source.
>> 
>>  This is the first gnuplot release prepared from git rather than cvs.
>>  The release corresponds to git commit 
> 77a494497d6beb9d09e71643c186e8ab891bbe7e
>>  Should this be captured somewhere in the release source?
>>  Where?
>> 
>>  CHANGES IN 5.2.3
>>  ================
>>  * NEW "set grid {no}vertical" adds grid lines in the xz and xz 
> planes
>>  * NEW "set cntrparam {firstlinetype N} {{un}sorted}"
>>  * CHANGE drop non-working support for YIQ color space
>>  * CHANGE expand \n characters when printing into a datablock
>>  * CHANGE allow contour plots to opt out of hidden3d processing
>>  * CHANGE special-case code to speed up handling of logscale axes
>>  * CHANGE do not write GPFUN_* variables to "save" output file
>>  * CHANGE default to density 100 for "set fs solid", 50 for 
> "set 
>>  fs transparent"
>>  * FIX potential buffer overflow in gprintf formats containing %%
>>  * FIX immediate response to ctrl-Z when libreadline is used for input
>>  * FIX warning messages inside a bracketed clause could trigger early exit
>>  * FIX tweak logscale tic range limits and minor tic generation intervals
>>  * FIX stats FOO using 'namedcolumn' name columnhead
>>  * FIX clipping of INRANGE->UNDEFINED line segments
>>  * FIX use of logscale y axis in "set view map" or "set pm3d 
>>  map" modes
>>  * FIX placement of colorbox in "set view map" mode
>>  * FIX autoscaled axis range of logscale axes in "set view map" 
> mode
>>  * FIX polar mode "with yerrorbars" error bars are radial, not 
> vertical
>>  * FIX clipping of circles whose center is offscreen to the left or bottom
>>  * FIX canvas terminal: apply both color and alpha channel to points and 
> lines
>>  * FIX svg terminal: apply current color to dots
>>  * FIX qt terminal: include "notitle" plots in accounting for 
> toggle 
>>  operations
>>  * FIX svg terminal: point plot empty title produced spurious mousing 
> directive
>>  * FIX tikz terminal: failed to recognize dashtype 1
>> 
>> 
>>      Ethan
>> 
>> 
> ------------------------------------------------------------------------------
>>  Check out the vibrant tech community on one of the world's most
>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via: 
>>  https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

I cannot build the source of 5.2.3 (that could be build on testing).

gcc -c -I/c/Programs/gplibs64_gcc710/include -D_FILE_OFFSET_BITS=64  -DDEFAULTTERM=\"wxt\" -m64 -O2 -pipe -DUNICODE -D_UNICODE -Wno-unused-function -I. -I../../src -I../../term/ -D_Windows -DHAVE_CONFIG_H -DPIPES -DWGP_CONSOLE -D__USE_MINGW_ANSI_STDIO=1 -DGNUPLOT_SHARE_DIR=\"share\" -DUSE_MOUSE=1 -DWIN_IPC -I/c/Program\ Files\ \(x86\)/HTML\ Help\ Workshop/include -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBGD -DHAVE_GD_H -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG -I/c/Programs/gplibs64_gcc710/include -DHAVE_GD_JPEG -DHAVE_GD_TTF -DHAVE_CAIROPDF -DWXWIDGETS -DHAVE_ICONV -DHAVE_LIBCERF -DNEED_CEXP -DREADLINE  -MMD -MT 'eval.$(O)' -MF eval.d -o eval.co ../../src/eval.c
In file included from ../../src/eval.h:43:0,
                 from ../../src/eval.c:41:
../../src/gp_types.h:188:5: error: unknown type name 'coordval'
     coordval x, y, z;
     ^~~~~~~~
../../src/gp_types.h:189:5: error: unknown type name 'coordval'
     coordval ylow, yhigh; /* ignored in 3d */
     ^~~~~~~~
 many errors

This might happen due to fixes after testing and 5.2.3.

Tatsuro



----- Original Message -----
> From: sfeam via gnuplot-beta 
> To: gnuplot-beta
> Cc: 
> Date: 2018/5/5, Sat 13:54
> Subject: Release 5.2.3
> 
> Source tarball for gnuplot 5.2.3 uploaded to SourceForge.
> 
> One trivial fix to initialization of postscript terminal added since
> last week's 5.2.3-testing source.
> 
> This is the first gnuplot release prepared from git rather than cvs.
> The release corresponds to git commit 77a494497d6beb9d09e71643c186e8ab891bbe7e
> Should this be captured somewhere in the release source?
> Where?
> 
> CHANGES IN 5.2.3
> ================
> * NEW "set grid {no}vertical" adds grid lines in the xz and xz planes
> * NEW "set cntrparam {firstlinetype N} {{un}sorted}"
> * CHANGE drop non-working support for YIQ color space
> * CHANGE expand \n characters when printing into a datablock
> * CHANGE allow contour plots to opt out of hidden3d processing
> * CHANGE special-case code to speed up handling of logscale axes
> * CHANGE do not write GPFUN_* variables to "save" output file
> * CHANGE default to density 100 for "set fs solid", 50 for "set 
> fs transparent"
> * FIX potential buffer overflow in gprintf formats containing %%
> * FIX immediate response to ctrl-Z when libreadline is used for input
> * FIX warning messages inside a bracketed clause could trigger early exit
> * FIX tweak logscale tic range limits and minor tic generation intervals
> * FIX stats FOO using 'namedcolumn' name columnhead
> * FIX clipping of INRANGE->UNDEFINED line segments
> * FIX use of logscale y axis in "set view map" or "set pm3d 
> map" modes
> * FIX placement of colorbox in "set view map" mode
> * FIX autoscaled axis range of logscale axes in "set view map" mode
> * FIX polar mode "with yerrorbars" error bars are radial, not vertical
> * FIX clipping of circles whose center is offscreen to the left or bottom
> * FIX canvas terminal: apply both color and alpha channel to points and lines
> * FIX svg terminal: apply current color to dots
> * FIX qt terminal: include "notitle" plots in accounting for toggle 
> operations
> * FIX svg terminal: point plot empty title produced spurious mousing directive
> * FIX tikz terminal: failed to recognize dashtype 1
> 
> 
>     Ethan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Source tarball for gnuplot 5.2.3 uploaded to SourceForge.

One trivial fix to initialization of postscript terminal added since
last week's 5.2.3-testing source.

This is the first gnuplot release prepared from git rather than cvs.
The release corresponds to git commit 77a494497d6beb9d09e71643c186e8ab891bbe7e
Should this be captured somewhere in the release source?
Where?

CHANGES IN 5.2.3
================
* NEW "set grid {no}vertical" adds grid lines in the xz and xz planes
* NEW "set cntrparam {firstlinetype N} {{un}sorted}"
* CHANGE drop non-working support for YIQ color space
* CHANGE expand \n characters when printing into a datablock
* CHANGE allow contour plots to opt out of hidden3d processing
* CHANGE special-case code to speed up handling of logscale axes
* CHANGE do not write GPFUN_* variables to "save" output file
* CHANGE default to density 100 for "set fs solid", 50 for "set fs transparent"
* FIX potential buffer overflow in gprintf formats containing %%
* FIX immediate response to ctrl-Z when libreadline is used for input
* FIX warning messages inside a bracketed clause could trigger early exit
* FIX tweak logscale tic range limits and minor tic generation intervals
* FIX stats FOO using 'namedcolumn' name columnhead
* FIX clipping of INRANGE->UNDEFINED line segments
* FIX use of logscale y axis in "set view map" or "set pm3d map" modes
* FIX placement of colorbox in "set view map" mode
* FIX autoscaled axis range of logscale axes in "set view map" mode
* FIX polar mode "with yerrorbars" error bars are radial, not vertical
* FIX clipping of circles whose center is offscreen to the left or bottom
* FIX canvas terminal: apply both color and alpha channel to points and lines
* FIX svg terminal: apply current color to dots
* FIX qt terminal: include "notitle" plots in accounting for toggle operations
* FIX svg terminal: point plot empty title produced spurious mousing directive
* FIX tikz terminal: failed to recognize dashtype 1


	Ethan

----- Original Message -----

> From: Allin Cottrell
> To: Tatsuro MATSUOKA 
> Cc: Merritt Ethan ; gnuplot-beta ; bmaerkisch
> Date: 2018/5/3, Thu 11:45
> Subject: Re: including fontconfig utilities to windows binary packages
> 
> On Thu, 3 May 2018, Tatsuro MATSUOKA wrote, in response to my posting:
> 
>>>  [I]insofar as we're talking about terminals based on the 
> pango/cairo/glib stack on Windows, there's no need to involve fontconfig (or 
> freetype) at all. The pango backends that are needed are just Cairo and Win32 
> (the Win32 backend being an alternative to freetype + fontconfig that taps into 
> native Windows font management).
>> 
>>  gd also requires fontconfig/freetype if one use standard syntax for fonts 
> for current gnuplot.
> 
> True. Opinions may differ, but personally I see no need to build the gd terminal 
> for gnuplot if the pango/cairo terminals are available.
> 
>>  If one compiles libraries of pango/cairo/glib in standard way on windows or 
> use libraries supplied by Msys2 + MinGW w64, freetype and fontconfig is linked 
> and gnuplot uses fontconfig/freetype libraries.
> 
> A build of pango, on any system, will by default utilize whatever backends are 
> available for managing fonts. If you have freetype and fontconfig on your system 
> the associated pango backend will be built unless you specify otherwise via the 
> configure script. But my point is that this backend is redundant on MS Windows, 
> since pango is able to utilize native Windows font management. (The same is true 
> on Mac OS X.)
> 
> There's no harm in enabling freetype and fontconfig for pango on Windows 
> (other than bloat), but so far as I can tell there's also no advantage.
> 
> Allin Cottrell
>

Thank for your explanations. 
I have misled about pango/cairo/glib.

But as a window version gnuplot builder, I cannot drop gd terminals with fontconfig/freetype because we have to provide full featured gnuplot as possible.

In addition, the easiest way to set-up build environments on native windows to install Msys2 with MinGW w64. The way of build on native windows is documented by Bastian.
  Build instructions using MSYS2/Mingw-w64
https://sourceforge.net/p/gnuplot/support-requests/199/

In that build system pango/cairo/glib libraries are prepared with linking fontconfig/freetype and
I do not think that there is no reason not to use fontconfig/freetype in the system.

Tatsuro

On Thu, 3 May 2018, Tatsuro MATSUOKA wrote, in response to my 
posting:

>> [I]insofar as we're talking about terminals based on the 
>> pango/cairo/glib stack on Windows, there's no need to involve 
>> fontconfig (or freetype) at all. The pango backends that are 
>> needed are just Cairo and Win32 (the Win32 backend being an 
>> alternative to freetype + fontconfig that taps into native 
>> Windows font management).
>
> gd also requires fontconfig/freetype if one use standard syntax 
> for fonts for current gnuplot.

True. Opinions may differ, but personally I see no need to build the 
gd terminal for gnuplot if the pango/cairo terminals are available.

> If one compiles libraries of pango/cairo/glib in standard way on 
> windows or use libraries supplied by Msys2 + MinGW w64, freetype 
> and fontconfig is linked and gnuplot uses fontconfig/freetype 
> libraries.

A build of pango, on any system, will by default utilize whatever 
backends are available for managing fonts. If you have freetype and 
fontconfig on your system the associated pango backend will be built 
unless you specify otherwise via the configure script. But my point 
is that this backend is redundant on MS Windows, since pango is able 
to utilize native Windows font management. (The same is true on Mac 
OS X.)

There's no harm in enabling freetype and fontconfig for pango on 
Windows (other than bloat), but so far as I can tell there's also no 
advantage.

Allin Cottrell

----- Original Message -----

> From: Allin Cottrell 
> To: Ethan A Merritt 
> Cc: gnuplot-beta Tatsuro MATSUOKA  bmaerkisch
 Date: 2018/5/3, Thu 02:57
> Subject: Re: including fontconfig utilities to windows binary packages
> 
> On Wed, 2 May 2018, Ethan A Merritt via gnuplot-beta wrote:
> 
>>  On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
>>>  I propose that we include fontconfig utilities to windows binary 
> packages.
>> 
>>  I do not know how fontconfig works on Windows.
>> 
>>  On linux fontconfig keeps track of all the fonts installed on the system,
>>  so installing it for only one program would not make sense.
>>  If you include fontconfig with a gnuplot binary for Windows, would you
>>  also have to include lots of fonts?  If so I don't think we want to do 
> that.
> 
> No, surely not. And insofar as we're talking about terminals based on the 
> pango/cairo/glib stack on Windows, there's no need to involve fontconfig (or 
> freetype) at all. The pango backends that are needed are just Cairo and Win32 
> (the Win32 backend being an alternative to freetype + fontconfig that taps into 
> native Windows font management).
> 
> Allin Cottrell

gd also requires fontconfig/freetype if one use standard syntax for fonts
for current gnuplot.

If one compiles libraries of pango/cairo/glib in standard way on windows or use libraries supplied by 
Msys2 + MinGW w64, freetype and  fontconfig is linked and 
gnuplot uses fontconfig/freetype libraries.

As I wrote, unlike unix system, each application has their on fontconfig setting like octave for windows and MiKTeX.

Therefore I had made proposal

Tatsuro

On Wed, 2 May 2018, Ethan A Merritt via gnuplot-beta wrote:

> On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
>> I propose that we include fontconfig utilities to windows binary packages.
>
> I do not know how fontconfig works on Windows.
>
> On linux fontconfig keeps track of all the fonts installed on the system,
> so installing it for only one program would not make sense.
> If you include fontconfig with a gnuplot binary for Windows, would you
> also have to include lots of fonts?  If so I don't think we want to do that.

No, surely not. And insofar as we're talking about terminals based on 
the pango/cairo/glib stack on Windows, there's no need to involve 
fontconfig (or freetype) at all. The pango backends that are needed 
are just Cairo and Win32 (the Win32 backend being an alternative to 
freetype + fontconfig that taps into native Windows font management).

Allin Cottrell

On Tuesday, May 1, 2018 7:56:54 PM PDT Tatsuro MATSUOKA wrote:
> I propose that we include fontconfig utilities to windows binary packages.

I do not know how fontconfig works on Windows.

On linux fontconfig keeps track of all the fonts installed on the system,
so installing it for only one program would not make sense.
If you include fontconfig with a gnuplot binary for Windows, would you
also have to include lots of fonts?  If so I don't think we want to do that.

	Ethan


> 
> That is done Kakuto's distribution of dev branch.
> http://ctan.ijs.si/mirror/w32tex/w32/
> 
> On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
> etcs. 
> I think that it is no reason that gnuplot for windows does not have them.
> Bastian. How do you think?
> 
> Tatsuro
> > 
> ----- Original Message -----
> > From: Tatsuro MATSUOKA <tma...@ya...>
> > To: gnu...@li...; Merritt Ethan <sf...@us...>; bma...@we...
> > Cc: 
> > Date: 2018/4/30, Mon 09:03
> > Subject: including fontconfig utilities to windows binary packages
> > 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

I propose that we include fontconfig utilities to windows binary packages.


That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
etcs. 
I think that it is no reason that gnuplot for windows does not have them.
Bastian. How do you think?

Tatsuro

I propose that we include fontconfig utilities to windows binary packages.


That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, 
etcs. 
I think that it is no reason that gnuplot for windows does not have them.
Bastian. How do you think?

Tatsuro
> 
----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: gnu...@li...; Merritt Ethan <sf...@us...>; bma...@we...
> Cc: 
> Date: 2018/4/30, Mon 09:03
> Subject: including fontconfig utilities to windows binary packages
> 

I propose that we include fontconfig utilities to windows binary packages.

That is done Kakuto's distribution of dev branch.
http://ctan.ijs.si/mirror/w32tex/w32/

On windows, each application has self fontconfig utilities like TeX, GNU Octave, etcs. 
I think that it is no reason that gnuplot for windows does not have them.

Bastian. How do you think?

Tatsuro

On Friday, 27 April 2018 13:18:50 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> >> Yeah. I think the auto-writeback logic proposed earlier is the more
> >> complete way to do this.
> 
> A crude prototype patch is attached. It unconditionally saves the
> writeback before each plot, and unconditionally restores it before each
> refresh (not replot). Works for the test case here. With a bit of
> extending, I'd like to see something like this be included.

Looks promising!

I have applied your patch, lightly edited, to the development version
and removed the code it replaces.  The change fixes a problem with
"refresh" in 3D plots that I was not aware of.

I'd like to see this change tested in the development version for
one cycle before applying it to the stable series, because it does
change the use of the axis writeback flag and so has in theory a
potential to break existing scripts that use "set xrange nowriteback".
That was always a very obscure option so there may well not be any
such scripts.

While testing I managed to trigger a bad state after an "unzoom"
operation of a plot with logscale axes.  But then I couldn't 
reproduce it so I can't say for sure that it was really the new
code at fault.  It's hard to automate testing of zoom/unzoom
and window redraw operations.

If no one complains about the changed status of the writeback flag
there is one further step of simplification possible by setting that
flag in the default axis structures for x/y/etc rather than 
setting it all over again in every plot and splot command.

	Ethan 

I have uploaded 5.2.3 testing windows binary packages.

Tatsuro



----- Original Message -----
> From: Tatsuro MATSUOKA <tma...@ya...>
> To: Merritt Ethan <sf...@us...>; gnu...@li...
> Cc: 
> Date: 2018/4/28, Sat 10:52
> Subject: Re: pre-release testing version of gnuplot 5.2.3
> 
> Now I am compiling on windows.
> After fishing I will upload windows binary packages on the testing directory.
> 
> Tatsuro
> 
> 
> 
> ----- Original Message -----
>>  From: sfeam via gnuplot-beta <gnu...@li...>
>>  To: gnu...@li...
>>  Cc: 
>>  Date: 2018/4/27, Fri 10:31
>>  Subject: pre-release testing version of gnuplot 5.2.3
>> 
>>  I have uploaded a 5.2.3 tarball to the "testing" section of the
>>  gnuplot files folder on SourceForge.
>>    
>>      https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>>      gnuplot-5.2.3-testing.tar.gz
>> 
>> 
>>  So far as I know there is nothing unusual about this patchlevel
>>  release.  It is the usual mix of bugfixes and a few features 
>>  back-ported from the development version.  However it is the first
>>  release tarball prepared from a git branch rather than from our
>>  old cvs repository.  That shouldn't make any difference but I
>>  suppose it is possible that something comes out a little different.
>> 
>>  Please use the testing tarball to confirm a successful build or
>>  report build errors.  If no problems are found I expect to make a
>>  regular release of 5.2.3 next week.
>> 
>>      Ethan
>> 
>> 
> ------------------------------------------------------------------------------
>>  Check out the vibrant tech community on one of the world's most
>>  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via: 
>>  https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Now I am compiling on windows.
After fishing I will upload windows binary packages on the testing directory.

Tatsuro



----- Original Message -----
> From: sfeam via gnuplot-beta <gnu...@li...>
> To: gnu...@li...
> Cc: 
> Date: 2018/4/27, Fri 10:31
> Subject: pre-release testing version of gnuplot 5.2.3
> 
> I have uploaded a 5.2.3 tarball to the "testing" section of the
> gnuplot files folder on SourceForge.
>   
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>     gnuplot-5.2.3-testing.tar.gz
> 
> 
> So far as I know there is nothing unusual about this patchlevel
> release.  It is the usual mix of bugfixes and a few features 
> back-ported from the development version.  However it is the first
> release tarball prepared from a git branch rather than from our
> old cvs repository.  That shouldn't make any difference but I
> suppose it is possible that something comes out a little different.
> 
> Please use the testing tarball to confirm a successful build or
> report build errors.  If no problems are found I expect to make a
> regular release of 5.2.3 next week.
> 
>     Ethan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Ethan A Merritt <sf...@us...> writes:

>> Yeah. I think the auto-writeback logic proposed earlier is the more
>> complete way to do this.

A crude prototype patch is attached. It unconditionally saves the
writeback before each plot, and unconditionally restores it before each
refresh (not replot). Works for the test case here. With a bit of
extending, I'd like to see something like this be included.

On Friday, April 27, 2018 11:21:29 AM PDT Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > The stupid error I found was in code that only dealt with the x axis
> > of the current plot (so either x or x2).
> 
> Hmmm. I see a very outwardly-similar problem if I "set logscale y"
> instead of "set logscale x" in that test script. Do you see it too?

Yes I see it too.
But there is no y axis fixup code analogous to the x axis fixup code,
So there is not an analogous stupid error that I can fix with one line of code.

	Ethan

> >> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
> >> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
> >> probably.
> >
> > A higher-level fix is required so that all axes are correctly re-evaluated
> > on refresh.  The difficulty comes from trying to handle both pure
> > "replot/refresh" requests and zoom operations.
> 
> Yeah. I think the auto-writeback logic proposed earlier is the more
> complete way to do this.

Ethan A Merritt <sf...@us...> writes:

> The stupid error I found was in code that only dealt with the x axis
> of the current plot (so either x or x2).

Hmmm. I see a very outwardly-similar problem if I "set logscale y"
instead of "set logscale x" in that test script. Do you see it too?


>> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
>> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
>> probably.
>
> A higher-level fix is required so that all axes are correctly re-evaluated
> on refresh.  The difficulty comes from trying to handle both pure
> "replot/refresh" requests and zoom operations.

Yeah. I think the auto-writeback logic proposed earlier is the more
complete way to do this.

Thanks
dima

On Thursday, April 26, 2018 11:50:25 PM PDT Dima Kogan wrote:
> sfeam <sf...@us...> writes:
> 
> > Heh.  And indeed I found a stupid error that failed to check for
> > logscaling at one point during the "refresh" command that is substituted
> > for "replot" for inline data.  I make no guarantee that it fixes
> > everything but it does work on your test script.
> >
> > The larger routine that this error is embedded in all looks suspect
> > to me, but changing the whole thing is more than I'm going to tackle
> > right now.
> >
> > Can you test the stupid-error fix using git tip for the development
> > version? I'll run some additional tests here also. If nothing bad
> > turns up I'll make a decision about including it in 5.2.3 also.
> 
> Thanks for doing this so quickly. I just tested it, and it indeed makes
> the test script work. Your commit to fix that problem only touches the x
> axis. I changed the test script to "set logscale y" instead of x to see
> if that's also broken, and indeed it is. Can you do whatever you did
> with the x axis to the y axis?

The stupid error I found was in code that only dealt with the x axis
of the current plot (so either x or x2).

> I can imagine that x2 and y2 axes are affected and maybe 3d axes. And
> maybe other stuff. Handling x,y,x2,y2 should hit most of the use cases,
> probably.

A higher-level fix is required so that all axes are correctly re-evaluated
on refresh.  The difficulty comes from trying to handle both pure
"replot/refresh" requests and zoom operations.  

	Ethan