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

Re: Problems building 6.0.rc2

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

On Fri, 13 Oct 2023 17:22:38 -0700
Ethan A Merritt <me...@uw...> wrote:

> On Friday, 13 October 2023 15:06:27 PDT Philipp K. Janert via
> gnuplot-beta wrote:
> > 
> > I am encountering a compilation error when
> > trying to build from the current rc2 tarball.
> > 
> > After ./configure and make, several files
> > compile, until I hit this (more details in
> > attached text file):  
> 
> Thanks for the report.
> 
> Yeah, there is a mis-matched curly bracket in the conditional
> compilation logic for building the PostScript terminal if neither gd
> or cairo is also built.

Thanks! (But see my other mail.)

> 
> This is bug #2659
>    https://sourceforge.net/p/gnuplot/bugs/2659/
> 
> Fixed in this commit for -rc3
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> commit 67db7c4e11b769018d74c432136fb1c84ab985d0
> Author: Peter Korsgaard <pe...@ko...>
> Date:   Sun Oct 1 10:20:31 2023 +0200
> 
>     term/post.trm: unbreak !HAVE_DEFLATE_ENCODER builds
>     
>     Commit 2f2cf617808 (post: handle RGBA images (only current use is
> to render a pixmap)) added an extra '}' outside the
> HAVE_DEFLATE_ENCODER (gd support) conditional, leading to build
> breakage: 
>     In file included from term.h:298,
>                      from term.c:1211:
>     ../term/post.trm:4016:11: error: expected declaration specifiers
> or '...' before string constant 4016 |     fputs("%%%%BeginImage\n",
> gppsfile); 
>     http://autobuild.buildroot.net/results/5676609b6331b645f2e557aca67afe4c3a087433/build-end.log
>     
>     Fix it by dropping the extra { } added by the above commit.
>     
>     Signed-off-by: Peter Korsgaard <pe...@ko...>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> Minimal patch attached
> 
> 
>     Ethan
> 
> 
> 
> 
> > 
> > 
> > In file included from term.h:289,
> >                  from term.c:1219:
> > ../term/post.trm:4036:11: error: expected declaration specifiers or
> > ‘...’ before string constant 4036 |     fputs("%%%%BeginImage\n",
> > gppsfile); |           ^~~~~~~~~~~~~~~~~~
> > ../term/post.trm:4036:31: error: expected declaration specifiers or
> > ‘...’ before ‘gppsfile’ 4036 |     fputs("%%%%BeginImage\n",
> > gppsfile); |                               ^~~~~~~~
> > 
> > 
> > 
> > I currently don't have devel packages for
> > pango, cairo, etc installed, but I thought
> > gnuplot should still build with the "dumb"
> > terminal at least. Or am I missing some
> > build-tool? (This is on Linux Mint 21.)
> > 
> > I can provide more detail. What would be
> > most helpful?
> > 
> > Best,
> > 
> > 		Ph.
> > 
> >   

Re: Problems building 6.0.rc2

[Ethan A M. <me...@uw...>]

On Friday, 13 October 2023 15:06:27 PDT Philipp K. Janert via gnuplot-beta wrote:
> 
> I am encountering a compilation error when
> trying to build from the current rc2 tarball.
> 
> After ./configure and make, several files
> compile, until I hit this (more details in
> attached text file):

Thanks for the report.

Yeah, there is a mis-matched curly bracket in the conditional compilation
logic for building the PostScript terminal if neither gd or cairo is also built.

This is bug #2659
   https://sourceforge.net/p/gnuplot/bugs/2659/

Fixed in this commit for -rc3

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
commit 67db7c4e11b769018d74c432136fb1c84ab985d0
Author: Peter Korsgaard <pe...@ko...>
Date:   Sun Oct 1 10:20:31 2023 +0200

    term/post.trm: unbreak !HAVE_DEFLATE_ENCODER builds
    
    Commit 2f2cf617808 (post: handle RGBA images (only current use is to render
    a pixmap)) added an extra '}' outside the HAVE_DEFLATE_ENCODER (gd support)
    conditional, leading to build breakage:
    
    In file included from term.h:298,
                     from term.c:1211:
    ../term/post.trm:4016:11: error: expected declaration specifiers or '...' before string constant
     4016 |     fputs("%%%%BeginImage\n", gppsfile);
    
    http://autobuild.buildroot.net/results/5676609b6331b645f2e557aca67afe4c3a087433/build-end.log
    
    Fix it by dropping the extra { } added by the above commit.
    
    Signed-off-by: Peter Korsgaard <pe...@ko...>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Minimal patch attached


    Ethan




> 
> 
> In file included from term.h:289,
>                  from term.c:1219:
> ../term/post.trm:4036:11: error: expected declaration specifiers or
> ‘...’ before string constant 4036 |     fputs("%%%%BeginImage\n",
> gppsfile); |           ^~~~~~~~~~~~~~~~~~
> ../term/post.trm:4036:31: error: expected declaration specifiers or
> ‘...’ before ‘gppsfile’ 4036 |     fputs("%%%%BeginImage\n", gppsfile);
>       |                               ^~~~~~~~
> 
> 
> 
> I currently don't have devel packages for
> pango, cairo, etc installed, but I thought
> gnuplot should still build with the "dumb"
> terminal at least. Or am I missing some
> build-tool? (This is on Linux Mint 21.)
> 
> I can provide more detail. What would be
> most helpful?
> 
> Best,
> 
> 		Ph.
> 
> 

Problems building 6.0.rc2

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

I am encountering a compilation error when
trying to build from the current rc2 tarball.

After ./configure and make, several files
compile, until I hit this (more details in
attached text file):



In file included from term.h:289,
                 from term.c:1219:
../term/post.trm:4036:11: error: expected declaration specifiers or
‘...’ before string constant 4036 |     fputs("%%%%BeginImage\n",
gppsfile); |           ^~~~~~~~~~~~~~~~~~
../term/post.trm:4036:31: error: expected declaration specifiers or
‘...’ before ‘gppsfile’ 4036 |     fputs("%%%%BeginImage\n", gppsfile);
      |                               ^~~~~~~~



I currently don't have devel packages for
pango, cairo, etc installed, but I thought
gnuplot should still build with the "dumb"
terminal at least. Or am I missing some
build-tool? (This is on Linux Mint 21.)

I can provide more detail. What would be
most helpful?

Best,

		Ph.

-- 

Philipp K. Janert
www.janert.me

Second release candidate for gnuplot 6

[Ethan A M. <me...@uw...>]

The "testing" directory on SourceForge now has a tarball for gnuplot-6-0-rc2

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-6.0.rc2.tar.gz

This is a second release candidate for version 6.0.


	Gnuplot Version 6.0 rc2 Release Notes
	=====================================

Version 6.0 is the start of a new stable release series.
Work on gnuplot 6 has proceeded in parallel with the incremental updates to
version 5.4 over the past three years.  The new version introduces extensions
to the gnuplot command language, support for new output protocols, and
additional plotting styles.  Backwards compatibility is given high priority
in gnuplot development, so users should find no significant changes required
for techniques or code they are currently using with gnuplot 5.

Your feedback from testing of this release candidate will contribute to
the success of a full 6.0 release expected later in 2023.

Release Notes date:  18-Sep-2023

	Features introduced in version 6
	================================
For a detailed list of new features, with illustrations, see
  http://gnuplot.info/docs_6.0/NewFeatures.html

For more example plots see
  http://gnuplot.info/demo_6.0/

  - Function blocks and scoped variables
  - Larger collection of special and complex-valued functions
  - New plot styles
	o 2D plot style `with surface` works in 2D polar coordinates to produce a
	  solid-fill gridded representation of the plane. This is analogous to the
	  use of dgrid3d and pm3d to produce a 3D gridded surface.
	o 2D plot style `with sectors` renders one annular segment ("sector") for
	  each line of input data. This style can generate pie and donut charts,
	  windrose charts, and a polar equivalent to sparse-matrix heatmaps.
	o 2D plot style `with lines` now has a filter option `sharpen`.
	  This filter detects spikes in a function plot that would be missed or
	  under-represented due to coarse sampling.  It adds an additional
	  sampling point at the location of each such peak.
	o 3D plot style `with contourfill` produces 2D or 3D surfaces with
	  distinct z-ranges indicated by solid color fill.
  - Hulls, masks, and smoothing
	o A cluster of 2D points can be replaced by a bounding polygon ("hull").
	  Both convex hulls and concave hulls (χ-shapes) are supported.
	o Any hull or other closed path can be used as a mask to display only
	  selected regions of a pm3d surface or image plot.
	o New smoothing option "smooth path" can be used on 2D and 3D curves
	  that are not monotonic on x or y.  This allows smoothing of hulls.
  - Named palettes
	o The current palette can be saved to a named colormap for future us.
	o A predefined palette named "viridis" is provided.
	o Plots can specify a previously saved palette by name.
	  This permits the use of multiple palettes in a single plot command.
	o Named palettes can be edited to contain an alpha channel.
  - New built-in functions and array operations
	o palette(z) returns the current RGB palette color mapping for z.
	o rgbcolor("name") returns the 32bit ARGB value for a named color.
	o index(Array, element) returns the first index i for which Array[i]
	  is equal to element.
	o split("string", "separator") unpacks the fields in a string into
	  an array of strings.
	o join(array, "separator") is the complement to split().
	  It concatenates the elements of a string array into a single string.
	o `stats <non-existent file>` yields a testable value with no error;
	  useful to avoid errors or warnings in scripts.
  - Program control flow
	o New syntax if {...} else if {...} else {...}
	o XDG base directory conventions for configuration files are supported.
	o `unset warnings` suppresses output of warning messages to the console.
	o The `fit` command is protected by exception handling. Control always
	  returns to the next line of input even in the case of fit errors.
	  On return FIT_ERROR is non-zero if an error occurred.
	o "Watchpoints"  are target values associated with individual plots
	  in a graph. As that plot is drawn, each component line segment is
	  monitored to see if its endpoints bracket the target value of a
	  watchpoint coordinate (x, y, or z) or function f(x,y).
	  If a match is found, the [x,y] coordinates of the match point are
	  saved for later use.  Possible uses include
		- find the intersection points of two curves
		- find zeros of a function
		- find and notate where a dependent variable or function f(x,y)
		  crosses a threshold value
		- use the mouse to track values along multiple plots simultaneously
  - New terminals and terminal options
	o Terminals that display graphics in the same window as text entry now
	  support pseudo-mousing; i.e. they respond to arrow keys and other
	  hot-key bindings during "pause mouse".
	o New terminals kittygd and kittycairo provide in-window graphics for
	  terminal emulators that support the kitty protocol.
	o New terminal webp generates a single frame or an animation sequence
	  using webp encoding. Frames are generated using pngcairo,
	  then encoded through the WebPAnimEncoder API.
	o New terminal block for text-mode pseudo-graphics uses Unicode block
	  or Braille characters to offer improved resolution compared to the
	  dumb or caca terminals.
	o latex terminals standalone mode updated to work with texlive2023
  - Miscellaneous other new features
	o Time unit settings for major and minor axis tics.  For example,
	  minor tic marks can be placed at exactly one month intervals.
	o The character sequence $# in a using specifier evaluates to the total
	  number of columns available in the current line of data.
	  "plot FOO using 0:(column($# - 1))" plots the last-but-one field of each row.
	o keyword binvalue=avg plots the average, rather than the sum, of binned data.
	o "set colorbox bottom" places the color box underneath the plot.
	o "set pm3d spotlight" adds a user-controlled spotlight to the lighting model.
	o New key layout options to force specific width or number of columns.
	  Automatic positioning of the key on the page can be manually tweaked
	  by giving an offset.
	o "set isotropic" adjusts the axis scaling in both 2D and 3D plots such
	  that x, y, and z axes all have the same scale.
	o Text rotation angles are not limited to integral degree values.
	o Data-driven color assignments in plot style "histograms".


	Changes between 6.0 -rc1 and -rc2
	=================================
* New plot style "with contourfill" generates 2D and 3D contour plots with
  solid fill areas rather than lines.
* Support building against Qt6
	- ./configure falls back to Qt5 if the Qt6 libraries are not found
* Japanese documentation updated
	- added missing file title-ja.tex, build dependencies for mingw
* New configure option --enable-stable-sort
	- Use mergesort rather than qsort if the system provides it.
	- If neither mergesort nor glibc stable qsort is available,
	  modify internal gnuplot structures to contain a secondary sort key
* Render color gradient in colorbox as a pixel array
	- cairo, qt terminals
* "reset session" restores initial state of all linetype properties
	- previously only the colors were restored
	- now it also reinitializes linewidth, point and dash properties
* postscript terminal now handles pixmaps
* svg terminal now correctly tracks pattern-fill color

---------

happy gnuplotting

    Ethan

Gnuplot 5.4.9 release tarball

[Ethan A M. <me...@uw...>]

I have placed a release tarball of 5.4.9 on SourceForge

    https://sourceforge.net/projects/gnuplot/files/gnuplot/5.4.9/gnuplot-5.4.9.tar.gz

This is probably the final update to version 5.4,
as a full release of version 6 is expected by the end of this year.

In addition to a few bug fixes, it includes a change to the configuration system
to support linking against Qt6 (previous releases checked only for Qt5 or Qt4).  

Changes in 5.4.9
================
* NEW    qt:  support building with Qt6
* CHANGE check plugin version at time of import                         Bug #2629
* FIX    prevent segfault if GNUPLOT_DRIVER_DIR is invalid
* FIX    (regression) only y autoscale yerrorbars to points in xrange   Bug #2631
* FIX    possible memory corruption if clipping causes 0-size polygons
* FIX    wxt: initialization of key box toggle state
* FIX    post: handle pixmaps                                           Bug #2644


    Ethan

Re: First release candidate for gnuplot 6

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

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2023/07/23 日 16:17
> Subject: Re: First release candidate for gnuplot 6
> 
> 
> On Saturday, 22 July 2023 01:06:05 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > 
> > BTW, 
> > --enable-stable-sort
> > seems to be missing on 6.0.rc1 but is active on the dev. branch.
> > Is this intentional?
> > 
> > Tatsuro
> 
> There are several recent features in 6.1 that I felt were not yet polished
> enough or not yet tested enough to include immediately in 6.0.rc1.
> In order of introduction (oldest first) these are
> 
> - stable sort guarantees for Z-ordering of 3D plot elements 
> 
> - z slices of pm3d surfaces (z-clipping against both min and max of slice range)
>   and two new features that depend on z slice code changes:
>     "splot with contourfill" (depends on z-slices)
>     control over fill border line properties of individual 3D objects
> 
> - colorbox gradient rendered as a pixel map rather than as separate boxes
> 
> These can be considered for inclusion in a second release candidate for 6.0
> or stay in the development version for more work.
> You have probably tested the stable sort code as much as anyone.
> Do you think it should be added to the next 6.0 release candidate?
I myself do not have a strong opinion on this matter.
It will be grateful if it is implemented in the future.

> There are also a couple of changes in 6.1 that have been marked EXPERIMENTAL
> from the time they were first added and I did not include them in 6.0 rc1.
> IMHO these should be re-thought and a better or more complete implementation
> found before inclusion in a stable release.
> 
> - "set colorbox cbtics <linetype>"  (EXPERIMENTAL)
> - "using cbticlabels(<column>)"     (EXPERIMENTAL)
> 
> On the other hand, some other features that are still marked EXPERIMENTAL
> in the documentation are included in 6.0 rc1.
> That warning should maybe be removed if no problems are reported by
> people testing the release candidate.
> 
>     Ethan
> 
> 
> 

Re: First release candidate for gnuplot 6

[Ethan A M. <me...@uw...>]

On Saturday, 22 July 2023 01:06:05 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> 
> BTW, 
> --enable-stable-sort
> seems to be missing on 6.0.rc1 but is active on the dev. branch.
> Is this intentional?
> 
> Tatsuro

There are several recent features in 6.1 that I felt were not yet polished
enough or not yet tested enough to include immediately in 6.0.rc1.
In order of introduction (oldest first) these are

- stable sort guarantees for Z-ordering of 3D plot elements 

- z slices of pm3d surfaces (z-clipping against both min and max of slice range)
  and two new features that depend on z slice code changes:
    "splot with contourfill" (depends on z-slices)
    control over fill border line properties of individual 3D objects

- colorbox gradient rendered as a pixel map rather than as separate boxes

These can be considered for inclusion in a second release candidate for 6.0
or stay in the development version for more work.
You have probably tested the stable sort code as much as anyone.
Do you think it should be added to the next 6.0 release candidate?

There are also a couple of changes in 6.1 that have been marked EXPERIMENTAL
from the time they were first added and I did not include them in 6.0 rc1.
IMHO these should be re-thought and a better or more complete implementation
found before inclusion in a stable release.

- "set colorbox cbtics <linetype>"  (EXPERIMENTAL)
- "using cbticlabels(<column>)"     (EXPERIMENTAL)

On the other hand, some other features that are still marked EXPERIMENTAL
in the documentation are included in 6.0 rc1.
That warning should maybe be removed if no problems are reported by
people testing the release candidate.

    Ethan

Re: First release candidate for gnuplot 6

[ASSI <Str...@ne...>]

Ethan A Merritt writes:
> This is a first release candidate for version 6.0.

First attempt to build a test package for Cygwin:

make[1]: Entering directory '/mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/build/all/docs'
/bin/sh '/mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.rc1/missing' makeinfo -I/mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.rc1/docs gnuplot.texi --no-split --output=gnuplot.info
gnuplot.texi:13439: warning: @ref should not appear in @uref
gnuplot.texi:1952: @menu reference to nonexistent node `_int_floor_ceil_round::
'
make[1]: [Makefile:1260: gnuplot.info] Error 1 (ignored)

The actual culprit is an attempt to make an index node named
integer_conversion_functions:_int_floor_ceil_round, which contains the
illegal character ':'.  Changing the node name fixes the problem, for
instance with the following patch:

--8<---------------cut here---------------start------------->8---
--- origsrc/gnuplot-6.0.rc1/docs/gnuplot.doc
+++ src/gnuplot-6.0.rc1/docs/gnuplot.doc
@@ -2256,7 +2256,7 @@
  See `splot voxel-grids`, `vgrid`.
 @end table
 
-4 integer conversion functions: int floor ceil round
+4 integer conversion functions (int floor ceil round)
 ?integer conversion
 ?integer
 ?precision
--8<---------------cut here---------------end--------------->8---

Building the documentation then fails (apparently in ja/docs) because
gpinsetfigure.tex can not be found.  Manually building the documentation
again has trouble with figure_E0 even though it's present in the
directory and other figures do not present that problem.  Removing the
output files then running the productions again succeeds, so there is
some problem with the dependencies most likely.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Re: First release candidate for gnuplot 6

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

Hello
Thanks for your hard and excellent work.

BTW, 
--enable-stable-sort
seems to be missing on 6.0.rc1 but is active on the dev. branch.
Is this intentional?

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Date: 2023/07/21 金 12:16
> Subject: First release candidate for gnuplot 6
> 
> 
> The "testing" directory on SourceForge now has a tarball for gnuplot-6-0-rc1
> 
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-6.0.rc1.tar.gz
> 
> This is a first release candidate for version 6.0.
> 
> Nine years ago we went through three release candidates and six months of
> testing before releasing 5.0.  I expect that finalizing version 6.0 will
> go faster, but we will see.   Compared to the v4->v5 transition,
> I think v5->v6 introduces a larger number of new features but fewer
> changes that may affect existing scripts or user expectations.
> 
> 
> 
> 		Release Notes
> 		=============
> 
> Version 6.0 is the start of a new stable release series.
> Work on gnuplot 6 has proceeded in parallel with the incremental updates to
> version 5.4 over the past three years.  The new version introduces extensions
> to the gnuplot command language, support for new output protocols, and
> additional plotting styles.  Backwards compatibility is given high priority
> in gnuplot development, so users should find no significant changes required
> for techniques or code they are currently using with gnuplot 5.
> 
> Your feedback from testing of this release candidate will contribute to
> the success of a full 6.0 release expected later in 2023.
> 
> 	Features introduced in version 6
> 	================================
> 
> For a detailed list of new features, with illustrations, see
>   http://gnuplot.info/docs_6.0/NewFeatures.html
> 
> For more example plots see
>   http://gnuplot.info/demo_6.0/
> 
> - Function blocks and scoped variables
> - Larger collection of special and complex-valued functions
> - New plot styles
>         o 2D plot style `with surface` works in 2D polar coordinates to produce a
>           solid-fill gridded representation of the plane. This is analogous to the
>           use of dgrid3d and pm3d to produce a 3D gridded surface.
>         o 2D plot style `with sectors` renders one annular segment ("sector") for
>           each line of input data. This style can generate pie and donut charts,
>           windrose charts, and a polar equivalent to sparse-matrix heatmaps.
>         o 2D plot style `with lines` now has a filter option `sharpen`.
>           This filter detects spikes in a function plot that would be missed or
>           under-represented due to coarse sampling.  It adds an additional
>           sampling point at the location of each such peak.
> - Hulls, masks, and smoothing
>         o A cluster of 2D points can be replaced by a bounding polygon ("hull").
>           Both convex hulls and concave hulls (χ-shapes) are supported.
>         o Any hull or other closed path can be used as a mask to display only
>           selected regions of a pm3d surface or image plot.
>         o New smoothing option "smooth path" can be used on 2D and 3D curves
>           that are not monotonic on x or y.  This allows smoothing of hulls.
> - Named palettes
>         o The current palette can be saved to a named colormap for future us.
>         o A predefined palette named "viridis" is provided.
>         o Plots can specify a previously saved palette by name.
>           This permits the use of multiple palettes in a single plot command.
>         o Named palettes can be edited to contain an alpha channel.
> - New built-in functions and array operations
>         o palette(z) returns the current RGB palette color mapping for z.
>         o rgbcolor("name") returns the 32bit ARGB value for a named color.
>         o index(Array, element) returns the first index i for which Array[i]
>           is equal to element.
>         o split("string", "separator") unpacks the fields in a string into
>           an array of strings.
>         o join(array, "separator") is the complement to split().
>           It concatenates the elements of a string array into a single string.
>         o `stats <non-existent file>` yields a testable value with no error;
>           useful to avoid errors or warnings in scripts.
> - Program control flow
>         o New syntax if {...} else if {...} else {...}
>         o XDG base directory conventions for configuration files are supported.
>         o `unset warnings` suppresses output of warning messages to the console.
>         o The `fit` command is protected by exception handling. Control always
>           returns to the next line of input even in the case of fit errors.
>           On return FIT_ERROR is non-zero if an error occurred.
>         o "Watchpoints"  are target values associated with individual plots
>           in a graph. As that plot is drawn, each component line segment is
>           monitored to see if its endpoints bracket the target value of a
>           watchpoint coordinate (x, y, or z) or function f(x,y).
>           If a match is found, the [x,y] coordinates of the match point are
>           saved for later use.  Possible uses include
>                 - find the intersection points of two curves
>                 - find zeros of a function
>                 - find and notate where a dependent variable or function f(x,y)
>                   crosses a threshold value
>                 - use the mouse to track values along multiple plots simultaneously
> - New terminals and terminal options
>         o Terminals that display graphics in the same window as text entry now
>           support pseudo-mousing; i.e. they respond to arrow keys and other
>           hot-key bindings during "pause mouse".
>         o New terminals kittygd and kittycairo provide in-window graphics for
>           terminal emulators that support the kitty protocol.
>         o New terminal webp generates a single frame or an animation sequence
>           using webp encoding. Frames are generated using pngcairo,
>           then encoded through the WebPAnimEncoder API.
>         o New terminal block for text-mode pseudo-graphics uses Unicode block
>           or Braille characters to offer improved resolution compared to the
>           dumb or caca terminals.
>         o latex terminals standalone mode updated to work with texlive2023
> - Miscellaneous other new features
>         o Time unit settings for major and minor axis tics.  For example,
>           minor tic marks can be placed at exactly one month intervals.
>         o The character sequence $# in a using specifier evaluates to the total
>           number of columns available in the current line of data.
>           "plot FOO using 0:(column($# - 1))" plots the last-but-one field of each row.
>         o keyword binvalue=avg plots the average, rather than the sum, of binned data.
>         o "set colorbox bottom" places the color box underneath the plot.
>         o "set pm3d spotlight" adds a user-controlled spotlight to the lighting model.
>         o New key layout options to force specific width or number of columns.
>           Automatic positioning of the key on the page can be manually tweaked
>           by giving an offset.
>         o "set isotropic" adjusts the axis scaling in both 2D and 3D plots such
>           that x, y, and z axes all have the same scale.
>         o Text rotation angles are not limited to integral degree values.
>         o Data-driven color assignments in plot style "histograms".
> 
> 
>     happy gnuplotting
> 
> 	Ethan
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: First release candidate for gnuplot 6

[Dima K. <gn...@di...>]

Cool! I didn't realize there were so many new features. Thanks for
working on these.

First release candidate for gnuplot 6

[Ethan A M. <me...@uw...>]

The "testing" directory on SourceForge now has a tarball for gnuplot-6-0-rc1

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-6.0.rc1.tar.gz

This is a first release candidate for version 6.0.

Nine years ago we went through three release candidates and six months of
testing before releasing 5.0.  I expect that finalizing version 6.0 will
go faster, but we will see.   Compared to the v4->v5 transition,
I think v5->v6 introduces a larger number of new features but fewer
changes that may affect existing scripts or user expectations.



		Release Notes
		=============

Version 6.0 is the start of a new stable release series.
Work on gnuplot 6 has proceeded in parallel with the incremental updates to
version 5.4 over the past three years.  The new version introduces extensions
to the gnuplot command language, support for new output protocols, and
additional plotting styles.  Backwards compatibility is given high priority
in gnuplot development, so users should find no significant changes required
for techniques or code they are currently using with gnuplot 5.

Your feedback from testing of this release candidate will contribute to
the success of a full 6.0 release expected later in 2023.

	Features introduced in version 6
	================================

For a detailed list of new features, with illustrations, see
  http://gnuplot.info/docs_6.0/NewFeatures.html

For more example plots see
  http://gnuplot.info/demo_6.0/

- Function blocks and scoped variables
- Larger collection of special and complex-valued functions
- New plot styles
        o 2D plot style `with surface` works in 2D polar coordinates to produce a
          solid-fill gridded representation of the plane. This is analogous to the
          use of dgrid3d and pm3d to produce a 3D gridded surface.
        o 2D plot style `with sectors` renders one annular segment ("sector") for
          each line of input data. This style can generate pie and donut charts,
          windrose charts, and a polar equivalent to sparse-matrix heatmaps.
        o 2D plot style `with lines` now has a filter option `sharpen`.
          This filter detects spikes in a function plot that would be missed or
          under-represented due to coarse sampling.  It adds an additional
          sampling point at the location of each such peak.
- Hulls, masks, and smoothing
        o A cluster of 2D points can be replaced by a bounding polygon ("hull").
          Both convex hulls and concave hulls (χ-shapes) are supported.
        o Any hull or other closed path can be used as a mask to display only
          selected regions of a pm3d surface or image plot.
        o New smoothing option "smooth path" can be used on 2D and 3D curves
          that are not monotonic on x or y.  This allows smoothing of hulls.
- Named palettes
        o The current palette can be saved to a named colormap for future us.
        o A predefined palette named "viridis" is provided.
        o Plots can specify a previously saved palette by name.
          This permits the use of multiple palettes in a single plot command.
        o Named palettes can be edited to contain an alpha channel.
- New built-in functions and array operations
        o palette(z) returns the current RGB palette color mapping for z.
        o rgbcolor("name") returns the 32bit ARGB value for a named color.
        o index(Array, element) returns the first index i for which Array[i]
          is equal to element.
        o split("string", "separator") unpacks the fields in a string into
          an array of strings.
        o join(array, "separator") is the complement to split().
          It concatenates the elements of a string array into a single string.
        o `stats <non-existent file>` yields a testable value with no error;
          useful to avoid errors or warnings in scripts.
- Program control flow
        o New syntax if {...} else if {...} else {...}
        o XDG base directory conventions for configuration files are supported.
        o `unset warnings` suppresses output of warning messages to the console.
        o The `fit` command is protected by exception handling. Control always
          returns to the next line of input even in the case of fit errors.
          On return FIT_ERROR is non-zero if an error occurred.
        o "Watchpoints"  are target values associated with individual plots
          in a graph. As that plot is drawn, each component line segment is
          monitored to see if its endpoints bracket the target value of a
          watchpoint coordinate (x, y, or z) or function f(x,y).
          If a match is found, the [x,y] coordinates of the match point are
          saved for later use.  Possible uses include
                - find the intersection points of two curves
                - find zeros of a function
                - find and notate where a dependent variable or function f(x,y)
                  crosses a threshold value
                - use the mouse to track values along multiple plots simultaneously
- New terminals and terminal options
        o Terminals that display graphics in the same window as text entry now
          support pseudo-mousing; i.e. they respond to arrow keys and other
          hot-key bindings during "pause mouse".
        o New terminals kittygd and kittycairo provide in-window graphics for
          terminal emulators that support the kitty protocol.
        o New terminal webp generates a single frame or an animation sequence
          using webp encoding. Frames are generated using pngcairo,
          then encoded through the WebPAnimEncoder API.
        o New terminal block for text-mode pseudo-graphics uses Unicode block
          or Braille characters to offer improved resolution compared to the
          dumb or caca terminals.
        o latex terminals standalone mode updated to work with texlive2023
- Miscellaneous other new features
        o Time unit settings for major and minor axis tics.  For example,
          minor tic marks can be placed at exactly one month intervals.
        o The character sequence $# in a using specifier evaluates to the total
          number of columns available in the current line of data.
          "plot FOO using 0:(column($# - 1))" plots the last-but-one field of each row.
        o keyword binvalue=avg plots the average, rather than the sum, of binned data.
        o "set colorbox bottom" places the color box underneath the plot.
        o "set pm3d spotlight" adds a user-controlled spotlight to the lighting model.
        o New key layout options to force specific width or number of columns.
          Automatic positioning of the key on the page can be manually tweaked
          by giving an offset.
        o "set isotropic" adjusts the axis scaling in both 2D and 3D plots such
          that x, y, and z axes all have the same scale.
        o Text rotation angles are not limited to integral degree values.
        o Data-driven color assignments in plot style "histograms".


    happy gnuplotting

	Ethan

Re: SVG pixelation (was pdfcairo terminal seams between bars in the colorbox)

[Ethan A M. <me...@uw...>]

On Thursday, 13 July 2023 09:26:25 PDT Dima Kogan wrote:
> Dima Kogan <gn...@di...> writes:
> 
> > Most non-browser applications I've seen use rsvg: bug report here
> >
> >   https://urldefense.com/v3/__https://gitlab.gnome.org/GNOME/librsvg/-/issues/985__;!!K-Hz7m0Vt54!k39HeEQ9zt5kuFFtV54jBNfoBJvfqILRmzHarDU6bxyPm-2JXE1ruwmzZkCnARQ0hIggFA3zaJa59Jm0EojHJg$ 
> 
> Just an FYI. The rsvg upstream has fixed the issue, and closed the bug
> report (allegedly; I couldn't easily try it). But if it's fixed, then
> most non-browser client applications will show our pixelated images.

Except, apparently, on MacOS.
See discussion on 
   https://sourceforge.net/p/gnuplot/feature-requests/558/
   https://www.userlandia.com/home/2021/11/the-mystery-of-mac-os-mangled-image-interpolation-implementation

I'm in the process of combining suggestions from
Hiroki Motoyoshi (problems with MacOS)
and Alexander Täschner (problems with MSVC)
to hopefully end up with something that works for everyone.

    thanks

	Ethan

Re: SVG pixelation (was pdfcairo terminal seams between bars in the colorbox)

[Dima K. <gn...@di...>]

Dima Kogan <gn...@di...> writes:

> Most non-browser applications I've seen use rsvg: bug report here
>
>   https://gitlab.gnome.org/GNOME/librsvg/-/issues/985

Just an FYI. The rsvg upstream has fixed the issue, and closed the bug
report (allegedly; I couldn't easily try it). But if it's fixed, then
most non-browser client applications will show our pixelated images.

Re: strange multiplot behavior with wxt

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

On Thu, 29 Jun 2023, Allin Cottrell wrote:

> On Wed, 28 Jun 2023, Ethan A Merritt wrote:
>
>> Valgrind finds a test of an uninitialized flag "hidden" that could
>> plausibly be involved here.
>> I have corrected that by setting the flag to FALSE in the one place
>> that I could see initialization omitted, but I do not actually
>> understand why that code path is triggered by this test case (it is
>> the response to a "refresh" command).  That makes valgrind happy, so
>> maybe it will fix your display also.  I'll leave the tracker issue
>> "open" for now.
>
> Thanks, Ethan! I've built gnuplot 6.1.0 from gnuplot-main git and tested on 
> Fedora: it works fine. I'll also try on Arch with more recent wx, but it 
> looks like you've nailed the problem.

I can confirm that the fix also works for wx 3.2.2.

Allin Cottrell

Re: strange multiplot behavior with wxt

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

On Wed, 28 Jun 2023, Ethan A Merritt wrote:

> Valgrind finds a test of an uninitialized flag "hidden" that could
> plausibly be involved here.
> I have corrected that by setting the flag to FALSE in the one place
> that I could see initialization omitted, but I do not actually
> understand why that code path is triggered by this test case (it is
> the response to a "refresh" command).  That makes valgrind happy, so
> maybe it will fix your display also.  I'll leave the tracker issue
> "open" for now.

Thanks, Ethan! I've built gnuplot 6.1.0 from gnuplot-main git and 
tested on Fedora: it works fine. I'll also try on Arch with more 
recent wx, but it looks like you've nailed the problem.

Just wondering: are you likely to cherry-pick this fix into 
branch-5-4-stable?

Allin Cottrell

>
> On Wed, Jun 28, 2023 at 10:31 AM Allin Cottrell <cot...@wf...> wrote:
>>
>> On Wed, 28 Jun 2023, Ethan A Merritt wrote:
>>
>>> On Wednesday, 28 June 2023 05:50:15 PDT Allin Cottrell wrote:
>>>> I'm puzzled by a multiplot example where the output seems to be
>>>> non-deterministic -- though the fault may be in my script
>>>> (strange_multi.plt, attached).
>>>>
>>>> I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using
>>>> the wxt terminal for screen display with the command line
>>>>
>>>> gnuplot strange_multi.plt -persist
>>>
>>> I have kept source and executables around for many versions of gnuplot.
>>> I can reproduce your "missing bars in first plot" symptom with old
>>> executables for 5.4.0 through 5.4.6, but not with 5.4.8 or the
>>> development branch.  Any given executable seems to be 100% reproducible
>>> in either failing or succeeding.
>>>
>>> But here's the thing - if I rebuild 5.4.3 from the same original
>>> source, I get a new executable that does not exhibit the problem.
>>> So my suspicion is that the difference is the version of the
>>> wx- shared libraries the binary is linked against.
>>>
>>> old gnuplot_5.4.3 binary (built May 2022)
>>> [~/temp] ldd /usr/local/bin/gnuplot_5.4.3 | grep wx
>>>        libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007fc634b09000)
>>>        libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007fc634a25000)
>>>        libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007fc6349f6000)
>>>        libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007fc634000000)
>>>        libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007fc6349e2000)
>>>        libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007fc63497f000)
>>>        libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007fc633c00000)
>>>
>>> new gnuplot_5.4.3 binary (built today)
>>> [~/temp] ldd ~/cvs/gnuplot-5.4.3/src/gnuplot | grep wx
>>>        libwx_gtk3u_xrc-3.2.so.0 => /lib64/libwx_gtk3u_xrc-3.2.so.0 (0x00007f3cedc64000)
>>>        libwx_gtk3u_html-3.2.so.0 => /lib64/libwx_gtk3u_html-3.2.so.0 (0x00007f3cedb83000)
>>>        libwx_gtk3u_qa-3.2.so.0 => /lib64/libwx_gtk3u_qa-3.2.so.0 (0x00007f3cedb54000)
>>>        libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f3ced200000)
>>>        libwx_baseu_xml-3.2.so.0 => /lib64/libwx_baseu_xml-3.2.so.0 (0x00007f3cedb42000)
>>>        libwx_baseu_net-3.2.so.0 => /lib64/libwx_baseu_net-3.2.so.0 (0x00007f3cedade000)
>>>        libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f3cece00000)
>>>
>>> But it's only a suspicion. [...]
>>
>> I have a little more information to contribute. I'm testing my
>> example on two machines. The one I'm sitting at runs Fedora 36,
>> with gnuplot 5.4.3 and wx 3.0.5 (per wx-config). The linkage is
>>
>> myrtle:~$ ldd /usr/bin/gnuplot | grep wx
>>          libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fa5bfc00000)
>>          libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fa5bf800000)
>>
>> On this machine I'm seeing the non-deterministic behavior.
>>
>> The other machine I'm accessing remotely via ssh. It runs current
>> Arch Linux with gnuplot 5.4.8 and wx 3.2.2, linkage:
>>
>> robroy:~$ ldd /usr/bin/gnuplot | grep wx
>>          libwx_gtk3u_core-3.2.so.0 => /usr/lib/libwx_gtk3u_core-3.2.so.0 (0x00007f5447a00000)
>>          libwx_baseu-3.2.so.0 => /usr/lib/libwx_baseu-3.2.so.0 (0x00007f5447600000)
>>
>> On this more up-to-date system I now think I was wrong to say the
>> behavior is non-deterministic. The plot appears somewhat slowly over
>> the remote connection, and here's the reproducible sequence I'm
>> seeing over 2 or 3 seconds:
>>
>> * an empty (black) window appears
>> * the canvas goes to white
>> * the first subplot appears, correctly
>> * the second subplot appears, correctly
>> * the data portion of the first subplot is wiped out to white
>>
>> Might this help with diagnosis?
>>
>> Allin Cottrell

Re: strange multiplot behavior with wxt

[Ethan A M. <me...@uw...>]

Valgrind finds a test of an uninitialized flag "hidden" that could
plausibly be involved here.
I have corrected that by setting the flag to FALSE in the one place
that I could see initialization omitted, but I do not actually
understand why that code path is triggered by this test case (it is
the response to a "refresh" command).  That makes valgrind happy, so
maybe it will fix your display also.  I'll leave the tracker issue
"open" for now.


On Wed, Jun 28, 2023 at 10:31 AM Allin Cottrell <cot...@wf...> wrote:
>
> On Wed, 28 Jun 2023, Ethan A Merritt wrote:
>
> > On Wednesday, 28 June 2023 05:50:15 PDT Allin Cottrell wrote:
> >> I'm puzzled by a multiplot example where the output seems to be
> >> non-deterministic -- though the fault may be in my script
> >> (strange_multi.plt, attached).
> >>
> >> I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using
> >> the wxt terminal for screen display with the command line
> >>
> >> gnuplot strange_multi.plt -persist
> >
> > I have kept source and executables around for many versions of gnuplot.
> > I can reproduce your "missing bars in first plot" symptom with old
> > executables for 5.4.0 through 5.4.6, but not with 5.4.8 or the
> > development branch.  Any given executable seems to be 100% reproducible
> > in either failing or succeeding.
> >
> > But here's the thing - if I rebuild 5.4.3 from the same original
> > source, I get a new executable that does not exhibit the problem.
> > So my suspicion is that the difference is the version of the
> > wx- shared libraries the binary is linked against.
> >
> > old gnuplot_5.4.3 binary (built May 2022)
> > [~/temp] ldd /usr/local/bin/gnuplot_5.4.3 | grep wx
> >        libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007fc634b09000)
> >        libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007fc634a25000)
> >        libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007fc6349f6000)
> >        libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007fc634000000)
> >        libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007fc6349e2000)
> >        libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007fc63497f000)
> >        libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007fc633c00000)
> >
> > new gnuplot_5.4.3 binary (built today)
> > [~/temp] ldd ~/cvs/gnuplot-5.4.3/src/gnuplot | grep wx
> >        libwx_gtk3u_xrc-3.2.so.0 => /lib64/libwx_gtk3u_xrc-3.2.so.0 (0x00007f3cedc64000)
> >        libwx_gtk3u_html-3.2.so.0 => /lib64/libwx_gtk3u_html-3.2.so.0 (0x00007f3cedb83000)
> >        libwx_gtk3u_qa-3.2.so.0 => /lib64/libwx_gtk3u_qa-3.2.so.0 (0x00007f3cedb54000)
> >        libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f3ced200000)
> >        libwx_baseu_xml-3.2.so.0 => /lib64/libwx_baseu_xml-3.2.so.0 (0x00007f3cedb42000)
> >        libwx_baseu_net-3.2.so.0 => /lib64/libwx_baseu_net-3.2.so.0 (0x00007f3cedade000)
> >        libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f3cece00000)
> >
> > But it's only a suspicion. [...]
>
> I have a little more information to contribute. I'm testing my
> example on two machines. The one I'm sitting at runs Fedora 36,
> with gnuplot 5.4.3 and wx 3.0.5 (per wx-config). The linkage is
>
> myrtle:~$ ldd /usr/bin/gnuplot | grep wx
>          libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fa5bfc00000)
>          libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fa5bf800000)
>
> On this machine I'm seeing the non-deterministic behavior.
>
> The other machine I'm accessing remotely via ssh. It runs current
> Arch Linux with gnuplot 5.4.8 and wx 3.2.2, linkage:
>
> robroy:~$ ldd /usr/bin/gnuplot | grep wx
>          libwx_gtk3u_core-3.2.so.0 => /usr/lib/libwx_gtk3u_core-3.2.so.0 (0x00007f5447a00000)
>          libwx_baseu-3.2.so.0 => /usr/lib/libwx_baseu-3.2.so.0 (0x00007f5447600000)
>
> On this more up-to-date system I now think I was wrong to say the
> behavior is non-deterministic. The plot appears somewhat slowly over
> the remote connection, and here's the reproducible sequence I'm
> seeing over 2 or 3 seconds:
>
> * an empty (black) window appears
> * the canvas goes to white
> * the first subplot appears, correctly
> * the second subplot appears, correctly
> * the data portion of the first subplot is wiped out to white
>
> Might this help with diagnosis?
>
> Allin Cottrell



-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Re: strange multiplot behavior with wxt

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

On Wed, 28 Jun 2023, Ethan A Merritt wrote:

> On Wednesday, 28 June 2023 05:50:15 PDT Allin Cottrell wrote:
>> I'm puzzled by a multiplot example where the output seems to be
>> non-deterministic -- though the fault may be in my script
>> (strange_multi.plt, attached).
>>
>> I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using
>> the wxt terminal for screen display with the command line
>>
>> gnuplot strange_multi.plt -persist
>
> I have kept source and executables around for many versions of gnuplot.
> I can reproduce your "missing bars in first plot" symptom with old
> executables for 5.4.0 through 5.4.6, but not with 5.4.8 or the
> development branch.  Any given executable seems to be 100% reproducible
> in either failing or succeeding.
>
> But here's the thing - if I rebuild 5.4.3 from the same original
> source, I get a new executable that does not exhibit the problem.
> So my suspicion is that the difference is the version of the
> wx- shared libraries the binary is linked against.
>
> old gnuplot_5.4.3 binary (built May 2022)
> [~/temp] ldd /usr/local/bin/gnuplot_5.4.3 | grep wx
>        libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007fc634b09000)
>        libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007fc634a25000)
>        libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007fc6349f6000)
>        libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007fc634000000)
>        libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007fc6349e2000)
>        libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007fc63497f000)
>        libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007fc633c00000)
>
> new gnuplot_5.4.3 binary (built today)
> [~/temp] ldd ~/cvs/gnuplot-5.4.3/src/gnuplot | grep wx
>        libwx_gtk3u_xrc-3.2.so.0 => /lib64/libwx_gtk3u_xrc-3.2.so.0 (0x00007f3cedc64000)
>        libwx_gtk3u_html-3.2.so.0 => /lib64/libwx_gtk3u_html-3.2.so.0 (0x00007f3cedb83000)
>        libwx_gtk3u_qa-3.2.so.0 => /lib64/libwx_gtk3u_qa-3.2.so.0 (0x00007f3cedb54000)
>        libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f3ced200000)
>        libwx_baseu_xml-3.2.so.0 => /lib64/libwx_baseu_xml-3.2.so.0 (0x00007f3cedb42000)
>        libwx_baseu_net-3.2.so.0 => /lib64/libwx_baseu_net-3.2.so.0 (0x00007f3cedade000)
>        libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f3cece00000)
>
> But it's only a suspicion. [...]

I have a little more information to contribute. I'm testing my 
example on two machines. The one I'm sitting at runs Fedora 36,
with gnuplot 5.4.3 and wx 3.0.5 (per wx-config). The linkage is

myrtle:~$ ldd /usr/bin/gnuplot | grep wx
         libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fa5bfc00000)
         libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fa5bf800000)

On this machine I'm seeing the non-deterministic behavior.

The other machine I'm accessing remotely via ssh. It runs current 
Arch Linux with gnuplot 5.4.8 and wx 3.2.2, linkage:

robroy:~$ ldd /usr/bin/gnuplot | grep wx
         libwx_gtk3u_core-3.2.so.0 => /usr/lib/libwx_gtk3u_core-3.2.so.0 (0x00007f5447a00000)
         libwx_baseu-3.2.so.0 => /usr/lib/libwx_baseu-3.2.so.0 (0x00007f5447600000)

On this more up-to-date system I now think I was wrong to say the 
behavior is non-deterministic. The plot appears somewhat slowly over 
the remote connection, and here's the reproducible sequence I'm 
seeing over 2 or 3 seconds:

* an empty (black) window appears
* the canvas goes to white
* the first subplot appears, correctly
* the second subplot appears, correctly
* the data portion of the first subplot is wiped out to white

Might this help with diagnosis?

Allin Cottrell

Re: strange multiplot behavior with wxt

[Ethan A M. <me...@uw...>]

On Wednesday, 28 June 2023 05:50:15 PDT Allin Cottrell wrote:
> I'm puzzled by a multiplot example where the output seems to be 
> non-deterministic -- though the fault may be in my script 
> (strange_multi.plt, attached).
> 
> I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using 
> the wxt terminal for screen display with the command line
> 
> gnuplot strange_multi.plt -persist

I have kept source and executables around for many versions of gnuplot.
I can reproduce your "missing bars in first plot" symptom with old
executables for 5.4.0 through 5.4.6, but not with 5.4.8 or the
development branch.  Any given executable seems to be 100% reproducible
in either failing or succeeding.

But here's the thing - if I rebuild 5.4.3 from the same original
source, I get a new executable that does not exhibit the problem.
So my suspicion is that the difference is the version of the 
wx- shared libraries the binary is linked against.

old gnuplot_5.4.3 binary (built May 2022)
 [~/temp] ldd /usr/local/bin/gnuplot_5.4.3 | grep wx
        libwx_gtk3u_xrc-3.1.so.5 => /lib64/libwx_gtk3u_xrc-3.1.so.5 (0x00007fc634b09000)
        libwx_gtk3u_html-3.1.so.5 => /lib64/libwx_gtk3u_html-3.1.so.5 (0x00007fc634a25000)
        libwx_gtk3u_qa-3.1.so.5 => /lib64/libwx_gtk3u_qa-3.1.so.5 (0x00007fc6349f6000)
        libwx_gtk3u_core-3.1.so.5 => /lib64/libwx_gtk3u_core-3.1.so.5 (0x00007fc634000000)
        libwx_baseu_xml-3.1.so.5 => /lib64/libwx_baseu_xml-3.1.so.5 (0x00007fc6349e2000)
        libwx_baseu_net-3.1.so.5 => /lib64/libwx_baseu_net-3.1.so.5 (0x00007fc63497f000)
        libwx_baseu-3.1.so.5 => /lib64/libwx_baseu-3.1.so.5 (0x00007fc633c00000)

new gnuplot_5.4.3 binary (built today)
[~/temp] ldd ~/cvs/gnuplot-5.4.3/src/gnuplot | grep wx
        libwx_gtk3u_xrc-3.2.so.0 => /lib64/libwx_gtk3u_xrc-3.2.so.0 (0x00007f3cedc64000)
        libwx_gtk3u_html-3.2.so.0 => /lib64/libwx_gtk3u_html-3.2.so.0 (0x00007f3cedb83000)
        libwx_gtk3u_qa-3.2.so.0 => /lib64/libwx_gtk3u_qa-3.2.so.0 (0x00007f3cedb54000)
        libwx_gtk3u_core-3.2.so.0 => /lib64/libwx_gtk3u_core-3.2.so.0 (0x00007f3ced200000)
        libwx_baseu_xml-3.2.so.0 => /lib64/libwx_baseu_xml-3.2.so.0 (0x00007f3cedb42000)
        libwx_baseu_net-3.2.so.0 => /lib64/libwx_baseu_net-3.2.so.0 (0x00007f3cedade000)
        libwx_baseu-3.2.so.0 => /lib64/libwx_baseu-3.2.so.0 (0x00007f3cece00000)

But it's only a suspicion.  It could instead be a difference in some
other set of libraries, or in the compiler version used.  Or it could be
a timing issue that either is or is not triggered by generated code.
Perhaps the generated code for your semi-reproducible case hits right
on the edge of that timing. 
In any case I don't think the difference indicates a change in the gnuplot
source code.

Having said all that, if someone pins down the actual point of failure
or timing issue, perhaps we could code around it.   

	Ethan

> On some invocations the frequency bars appear in the first sub-plot, 
> on other invocations they do not appear, the upper plot shows no 
> data. But if I write the plot to file using, say, pngcairo or 
> pdfcairo, the first sub-plot is always OK.
> 
> Am I misusing multiplot or might there be a bug here?
> 
> 

strange multiplot behavior with wxt

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

I'm puzzled by a multiplot example where the output seems to be 
non-deterministic -- though the fault may be in my script 
(strange_multi.plt, attached).

I'm on Linux, using gnuplot 5.4.3 and also 5.4.8, using 
the wxt terminal for screen display with the command line

gnuplot strange_multi.plt -persist

On some invocations the frequency bars appear in the first sub-plot, 
on other invocations they do not appear, the upper plot shows no 
data. But if I write the plot to file using, say, pngcairo or 
pdfcairo, the first sub-plot is always OK.

Am I misusing multiplot or might there be a bug here?

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: Re: Commit [36a21d]

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

Ethan
Thanks for the reply.

>  Under Windows + mingw it is
This is also true on cygwin.
 
Under Windows + mingw and cygwin it is

Tatsuro
> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "Tatsuro MATSUOKA" <tma...@ya...>
> Cc: "beta" <gnu...@li...>
> Date: 2023/06/25 日 00:57
> Subject: Re: Commit [36a21d]
> 
> 
> Thank you for catching that.  The "-fPIC" flag should have been added
> to the previous example command, the one for linux.
> 
>   Ethan
> 
> On Fri, Jun 23, 2023 at 11:55 PM Tatsuro MATSUOKA via gnuplot-beta
> <gnu...@li...> wrote:
> >
> > I found in Commit [36a21d]
> > +++ b/demo/plugin/README
> > @@ -23,12 +23,12 @@
> >
> >  Under Windows + mingw it is
> >
> > -    gcc -shared -lm -o newprogram.dll newprogram.c
> > +    gcc -shared -lm -fPIC -o newprogram.dll newprogram.c
> >
> > As far as I know, -fPIC is not effective on WIndows.
> > https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=163949__;!!K-Hz7m0Vt54!jBF_aoqeTsaFf72wifSDQ-GopXPU9-4IpIwvRSENh-r0xtrJ-MD4LVRY3HP5A_6Br1lExVzif4elmnlMcXpyHjzUyma7UQ$
> >
> > Tatsuro
> >
> >
> >
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!jBF_aoqeTsaFf72wifSDQ-GopXPU9-4IpIwvRSENh-r0xtrJ-MD4LVRY3HP5A_6Br1lExVzif4elmnlMcXpyHjxbN-9g9w$
> 
> 
> 
> -- 
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle

Re: Commit [36a21d]

[Ethan A M. <me...@uw...>]

Thank you for catching that.  The "-fPIC" flag should have been added
to the previous example command, the one for linux.

  Ethan

On Fri, Jun 23, 2023 at 11:55 PM Tatsuro MATSUOKA via gnuplot-beta
<gnu...@li...> wrote:
>
> I found in Commit [36a21d]
> +++ b/demo/plugin/README
> @@ -23,12 +23,12 @@
>
>  Under Windows + mingw it is
>
> -    gcc -shared -lm -o newprogram.dll newprogram.c
> +    gcc -shared -lm -fPIC -o newprogram.dll newprogram.c
>
> As far as I know, -fPIC is not effective on WIndows.
> https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=163949__;!!K-Hz7m0Vt54!jBF_aoqeTsaFf72wifSDQ-GopXPU9-4IpIwvRSENh-r0xtrJ-MD4LVRY3HP5A_6Br1lExVzif4elmnlMcXpyHjzUyma7UQ$
>
> Tatsuro
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!jBF_aoqeTsaFf72wifSDQ-GopXPU9-4IpIwvRSENh-r0xtrJ-MD4LVRY3HP5A_6Br1lExVzif4elmnlMcXpyHjxbN-9g9w$



-- 
Ethan A Merritt
Department of Biochemistry
University of Washington, Seattle

Commit [36a21d]

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

I found in Commit [36a21d]
+++ b/demo/plugin/README
@@ -23,12 +23,12 @@
 
 Under Windows + mingw it is
 
-    gcc -shared -lm -o newprogram.dll newprogram.c
+    gcc -shared -lm -fPIC -o newprogram.dll newprogram.c

As far as I know, -fPIC is not effective on WIndows.
https://bugs.webkit.org/show_bug.cgi?id=163949

Tatsuro

Re: SVG pixelation (was pdfcairo terminal seams between bars in the colorbox)

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> I looked into it a bit further.
>
> The thing is, the two hinting properties you found are not part of the
> SVG standard (version 2).  They are instead CSS style hints to the browser.
> Chrome and Firefox apparently dive into an included SVG file and extract
> the CSS style hints from there. SVG-aware programs that are not browsers,
> like inkscape or gimp, could do the same but the motivation for doing
> so would come from imitating Chrome or Firefox rather than adhering to
> the SVG standard.  Inkscape does, but gimp doesn't. 
>
>> I'll file feature-request bug reports for those two projects.
>> But the patch should probably still go in: supporting firefox and chrome
>> is much better than supporting nothing.

> For me personally, the support from inkscape is just as important as
> from the browsers.  I use it to prepare figures for publication.
> And it's still true that you can work around this
> by using "with image pixels" for gnuplot heat maps. 
>
> What about lobbying the SVG working group to add an equivalent
> to the SVG spec?  All the various support libraries would then
> eventually fall in line.  As of SVG 2.0 you only get a choice
> between "optimizeSpeed" and "optimizeQuality", both of which
> are so vague as to be useless for our purpose.
>
>     https://svgwg.org/svg2-draft/painting.html#ImageRendering

That's interesting. Not sure what it means for us in practical terms.
The patch in this thread should cover most browsers. Most non-browser
applications I've seen use rsvg: bug report here

  https://gitlab.gnome.org/GNOME/librsvg/-/issues/985

I guess QT has its own implementation too; I ran out of steam, and
haven't pestered them. I don't know what libreoffice does, but it does
the right thing on my machine. And I don't know how to lobby the SVG
working group.

I would merge the patch in this thread, maybe file a bug report against
QSvg, and move on.

Re: SVG pixelation (was pdfcairo terminal seams between bars in the colorbox)

[Ethan A M. <me...@uw...>]

On Sunday, 18 June 2023 23:55:07 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > As tested here those attributes are indeed honored by firefox and chrome.
> > Mixed success on other svg handling programs.
> 
> I'm guessing that adding support for either image-rendering=crips-edge
> or image-rendering=pixelated into librsvg and QSvg would make all of
> these work. But it looks like these two libraries simply don't support
> either option yet.

I looked into it a bit further.

The thing is, the two hinting properties you found are not part of the
SVG standard (version 2).  They are instead CSS style hints to the browser.
Chrome and Firefox apparently dive into an included SVG file and extract
the CSS style hints from there. SVG-aware programs that are not browsers,
like inkscape or gimp, could do the same but the motivation for doing
so would come from imitating Chrome or Firefox rather than adhering to
the SVG standard.  Inkscape does, but gimp doesn't. 

> I'll file feature-request bug reports for those two projects.
> But the patch should probably still go in: supporting firefox and chrome
> is much better than supporting nothing.

For me personally, the support from inkscape is just as important as
from the browsers.  I use it to prepare figures for publication.
And it's still true that you can work around this
by using "with image pixels" for gnuplot heat maps. 

What about lobbying the SVG working group to add an equivalent
to the SVG spec?  All the various support libraries would then
eventually fall in line.  As of SVG 2.0 you only get a choice
between "optimizeSpeed" and "optimizeQuality", both of which
are so vague as to be useless for our purpose.

    https://svgwg.org/svg2-draft/painting.html#ImageRendering

Re: SVG pixelation (was pdfcairo terminal seams between bars in the colorbox)

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> As tested here those attributes are indeed honored by firefox and chrome.
> Mixed success on other svg handling programs.

I'm guessing that adding support for either image-rendering=crips-edge
or image-rendering=pixelated into librsvg and QSvg would make all of
these work. But it looks like these two libraries simply don't support
either option yet.

I'll file feature-request bug reports for those two projects.

But the patch should probably still go in: supporting firefox and chrome
is much better than supporting nothing.