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

Re: conditional text color?

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

Not exactly what you asked for, but one solution is to place the label in
an opaque box with neutral fillcolor:

   set style textbox opaque fc "grey" noborder
   plot $map1 matrix using 1:2:3 with image, \
        $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "black"
boxed

Here is a way to make it conditional on the matrix value using an extra
pass.
This requires gnuplot 6 for the "if" syntax

   plot $map1 matrix using 1:2:3 with image, \
       $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "black" if
($3 > -0.6), \
       $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "white" if
($3 <= -0.6)

cheers,
         Ethan


On Mon, Mar 23, 2026 at 10:02 AM Allin Cottrell via gnuplot-beta <
gnu...@li...> wrote:

> I have a gnuplot routine that shows a correlation matrix as a heat
> map. If the dimension of the matrix is not too great it prints the
> value of the correlation coefficient in each "cell". Mostly this
> works fine, but if the color of the cell is a relatively dark blue
> (indicating a strong negative correlation) the default black text is
> not very legible. So I'd like to make the textcolor conditional.
>
> At present I have this plot statement:
>
> plot $data matrix with image, $data matrix using \
>   1:2:(sprintf("%.1f",$3)) with labels
>
> I'd like to append something like
>
> tc $3 < -0.6 ? rgbcolor "white" : rgbcolor "black"
>
> That doesn't work ("colorspec option not recognized", not very
> surprisingly). But is there a way to do this?
>
> Thanks for any guidance.
>
> --
> Allin Cottrell
> Professor Emeritus
> Wake Forest University

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

Re: conditional text color?

[Cottrell, A. <cot...@wf...>]

Thanks, Ethan. I'm glad to be alerted to the "trailing if" syntax in
gnuplot 6; I hadn't noticed that.

Allin

On Mon, Mar 23, 2026 at 4:41 PM Ethan A Merritt <me...@uw...> wrote:
>
> Not exactly what you asked for, but one solution is to place the label in an opaque box with neutral fillcolor:
>
>    set style textbox opaque fc "grey" noborder
>    plot $map1 matrix using 1:2:3 with image, \
>         $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "black" boxed
>
> Here is a way to make it conditional on the matrix value using an extra pass.
> This requires gnuplot 6 for the "if" syntax
>
>    plot $map1 matrix using 1:2:3 with image, \
>        $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "black" if ($3 > -0.6), \
>        $map1 matrix using 1:2:(sprintf("%g",$3)) with labels tc "white" if ($3 <= -0.6)
>
> cheers,
>          Ethan
>
> On Mon, Mar 23, 2026 at 10:02 AM Allin Cottrell via gnuplot-beta <gnu...@li...> wrote:
>>
>> I have a gnuplot routine that shows a correlation matrix as a heat
>> map. If the dimension of the matrix is not too great it prints the
>> value of the correlation coefficient in each "cell". Mostly this
>> works fine, but if the color of the cell is a relatively dark blue
>> (indicating a strong negative correlation) the default black text is
>> not very legible. So I'd like to make the textcolor conditional.
>>
>> At present I have this plot statement:
>>
>> plot $data matrix with image, $data matrix using \
>>   1:2:(sprintf("%.1f",$3)) with labels
>>
>> I'd like to append something like
>>
>> tc $3 < -0.6 ? rgbcolor "white" : rgbcolor "black"
>>
>> That doesn't work ("colorspec option not recognized", not very
>> surprisingly). But is there a way to do this?
>>
>> Thanks for any guidance.

Re: conditional text color?

[Cottrell, A. <cot...@wf...>]

On Mon, Mar 23, 2026 at 3:36 PM Juhász Péter <pet...@gm...> wrote:
>
> On Mon, 2026-03-23 at 11:57 -0400, Allin Cottrell via gnuplot-beta
> wrote:
> > I have a gnuplot routine that shows a correlation matrix as a heat
> > map. If the dimension of the matrix is not too great it prints the
> > value of the correlation coefficient in each "cell". Mostly this
> > works fine, but if the color of the cell is a relatively dark blue
> > (indicating a strong negative correlation) the default black text is
> > not very legible. So I'd like to make the textcolor conditional.
> >
> > At present I have this plot statement:
> >
> > plot $data matrix with image, $data matrix using \
> >   1:2:(sprintf("%.1f",$3)) with labels
> >
> > I'd like to append something like
> >
> > tc $3 < -0.6 ? rgbcolor "white" : rgbcolor "black"
> >
> > That doesn't work ("colorspec option not recognized", not very
> > surprisingly). But is there a way to do this?
> >
> > Thanks for any guidance.
>
> Hi,
>
> AFAIK the labels style supports variable color. So you should be able
> to do something like
>
> $d << EOD
> 1 2 foo 0.3
> 2 3 bar 0.7
> EOD
>
> plot $d u 1:2:3:($4 > 0.6 ? 0xe00000 : 0x00e000) w labels tc rgb var
>
> In this case you'd have to specify the colors as integers, which may be
> slightly inconvenient and unmaintainable.

Actually that suits me fine; I don't mind giving the colors as ints.
Thanks for the suggestion!

Allin Cottrell

Re: conditional text color?

[Juhász P. <pet...@gm...>]

On Mon, 2026-03-23 at 11:57 -0400, Allin Cottrell via gnuplot-beta
wrote:
> I have a gnuplot routine that shows a correlation matrix as a heat 
> map. If the dimension of the matrix is not too great it prints the 
> value of the correlation coefficient in each "cell". Mostly this 
> works fine, but if the color of the cell is a relatively dark blue 
> (indicating a strong negative correlation) the default black text is 
> not very legible. So I'd like to make the textcolor conditional.
> 
> At present I have this plot statement:
> 
> plot $data matrix with image, $data matrix using \
>   1:2:(sprintf("%.1f",$3)) with labels
> 
> I'd like to append something like
> 
> tc $3 < -0.6 ? rgbcolor "white" : rgbcolor "black"
> 
> That doesn't work ("colorspec option not recognized", not very 
> surprisingly). But is there a way to do this?
> 
> Thanks for any guidance.

Hi,

AFAIK the labels style supports variable color. So you should be able
to do something like

$d << EOD
1 2 foo 0.3
2 3 bar 0.7    
EOD

plot $d u 1:2:3:($4 > 0.6 ? 0xe00000 : 0x00e000) w labels tc rgb var

In this case you'd have to specify the colors as integers, which may be
slightly inconvenient and unmaintainable. 
Other forms work too, like `tc variable` which would set the colors
based on the numbered color styles (same as used for functions/data by
the plot command), or `tc palette`, which draws colors according to a
color palette (either the default or the one you can set up before the
plot). This palette mode also draws a colorbar by default which you
have to disable if you don't want it.

So you have many options, neither of which is exactly what you want.

best regards,
Peter

conditional text color?

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

I have a gnuplot routine that shows a correlation matrix as a heat 
map. If the dimension of the matrix is not too great it prints the 
value of the correlation coefficient in each "cell". Mostly this 
works fine, but if the color of the cell is a relatively dark blue 
(indicating a strong negative correlation) the default black text is 
not very legible. So I'd like to make the textcolor conditional.

At present I have this plot statement:

plot $data matrix with image, $data matrix using \
  1:2:(sprintf("%.1f",$3)) with labels

I'd like to append something like

tc $3 < -0.6 ? rgbcolor "white" : rgbcolor "black"

That doesn't work ("colorspec option not recognized", not very 
surprisingly). But is there a way to do this?

Thanks for any guidance.

-- 
Allin Cottrell
Professor Emeritus
Wake Forest University

Gnuplot Release 6.0.4

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

The release package for gnuplot 6.0 patchlevel 4 source code is now
available on SourceForge.
    https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.4/gnuplot-6.0.4.tar.gz

Binary versions, including one for Windows on ARM64, will be available
from that same download folder on SourceForge.

Many thanks to everyone who reported problems or contributed to testing,
and especially to everyone who contributed fixes or new code via the
development branch.  Your involvement, no matter how small, helps to
keep gnuplot a powerful multi-platform tool as it enters its 40th year of
distribution -- gnuplot version 1.0 was announced in 1986. 
 
A few of those new features are included in the 6.0.4 stable release.
Please see the release notes for a summary of bug fixes and other minor
changes.

Release Notes
   Gnuplot 6.0.4 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html>

New Features

  • Support for Windows on ARM 64-bit architectures

  • New gprintf format specifiers for complex values
     %C  formats a complex value as {a, b}
          This is the format used by the gnuplot "print" command
     %Ci formats a complex value as a + bi
          Both the real and imaginary parts are printed using libc format %g
          with optional width and precision

  • Pre-defined variable Inf is set to floating point INFINITY

  • The "sharpen" filter handles vertical edges in a step function

  • 3D polygon objects rendered by "splot" can be assigned individual
     colors and fill styles

have fun plotting

    Ethan

gnuplot release 6.0.4 tarball

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

I have created a release directory on SourceForge for version 6.0.4

   https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.4/

The directory is "staged" for three days, which means only the developer
group can access it.  On 19 December it will become publically accessible
and I will send out a release announcement.

The release package includes Bastian's updates to the various Windows
configuration directories and build script (added since the testing versions),
and two final bug fixes.

The tarball content matches the state of git commit 3726262627

cheers,
        Ethan

Re: Backport request for 6.0.4 release version

[sfgphm <sf...@gm...>]

Dear Ethan,

I can confirm that all four issues in the test script have been resolved
with commit [4d3398fdd] to branch-6.0-stable.
Thank you very much for taking the time to backport this non-trivial fix.

Best regards,
H. Motoyoshi

On Thu, Dec 11, 2025 at 8:17 AM Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 9 December 2025 15:20:28 PST sfhm wrote:
> > Dear Ethan,
> >
> > I would like to request a backport to the 6.0.4 release.
> >
> > I have observed differences in polygon color rendering between the
> > development version and previous release versions (including
> > 6.0.4-testing). The development version renders polygons with the
> intended
> > colors, while the release versions render them with different colors.
>
> [snip example]
>
> > If the fix for this issue in the development version is sufficiently
> > stable, I would greatly appreciate its backport to the 6.0.4 release,
> even
> > if only for some of the cases rather than all of them.
>
> Unfortunately, that is not a trivial change.
>
> The code that deals with how fill color and border color are specified,
> stored, and eventually applied to graphical elements in the plot has
> diverged between 6.0 and the development branch.
>
> A partial list of relevant commits in 6.1 that do not apply cleanly to 6.0
>         c92721 fc9818
>
> Nevertheless, it is possible that the specific cases of "splot with
> polygons"
> in your test script could be handled either by some subset of the changes
> currently in the development branch or by some ad hoc fixes for 6.0.
> The trick is not to break anything else.
>
> I will look into it, but no promises about 6.0.4.
>
>  Ethan
>
>
>

Re: Pre-release testing version of gnuplot 6.0.4

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

On Friday, 12 December 2025 03:10:36 PST Bastian Märkisch via gnuplot-beta wrote:
> I have uploaded testing binaries for Windows x64 (clang), Windows on ARM 
> (clang), OS/2 (emx), DOS (djgpp) to the testing folder on SF.  They all 
> still needed some minor tweaks to the build process.
> 
> I also noted that neither the djgpp nor woa makefiles make it into the 
> source tarball at the moment.

The woa files are new, right?  
If they are to be included in the distribution tarball they need to be added
to the EXTRA_DIST list in config/Makefile.in.

So far as I can see, only two files related to djgpp are in that list
   config/config.dj2   config/djconfig.sh

Are these still needed?  Have they been superseded by
   config/djgpp/config.h  config/djgpp/Makefile

>    Bastian
> 
> Am 06.12.2025 um 03:13 schrieb Ethan A Merritt:
> > I have placed a testing version of the source release
> > package for gnuplot 6.0.4 on the "testing" section of the
> > SourceForge download site.
> > ...
> > My tentative plan is to announce the actual release in about
> > two weeks (the week of 15 December).  That can be pushed back
> > if you find any problems or want to suggest inclusion
> > of a bug-fix from the development version that was not yet
> > backported.

-- 
   Ethan

Re: Pre-release testing version of gnuplot 6.0.4

[Bastian M. <bma...@we...>]

I have uploaded testing binaries for Windows x64 (clang), Windows on ARM 
(clang), OS/2 (emx), DOS (djgpp) to the testing folder on SF.  They all 
still needed some minor tweaks to the build process.

I also noted that neither the djgpp nor woa makefiles make it into the 
source tarball at the moment.

   Bastian

Am 06.12.2025 um 03:13 schrieb Ethan A Merritt:
> I have placed a testing version of the source release
> package for gnuplot 6.0.4 on the "testing" section of the
> SourceForge download site.
>
>      https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> Nothing major to look for in this release, but it does include a number
> of recent bug fixes.　The configure script and various header files
> have been modified to allow use with C compilers that enforce c23
> syntax by default. This should not affect use with older compilers.
>
> My tentative plan is to announce the actual release in about
> two weeks (the week of 15 December).  That can be pushed back
> if you find any problems or want to suggest inclusion
> of a bug-fix from the development version that was not yet
> backported.
>
> Brief release notes below, or see
>       gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html
>
>
>
> %%%%%%%%%%    6.0.4 Release Notes 01-December-2025    %%%%%%%%%%%%%%%%
>
> NEW (back-ported from development version)
> ------------------------------------------
> * variable Inf is pre-set to floating point INFINITY
> * "sharpen" filter handles vertical edges in a step function
> * gprintf format specifiers %C and %Ci
>    - %C  formats a complex value as {a, b}
>        This is the format used by the gnuplot "print" command
>    - %Ci formats a complex value as a + bi
>        Both the real and imaginary parts are printed using libc format %g
>        with optional width and precision
> * Support for Windows on ARM 64-bit architectures
>    - mingw: optionally use the MSYS2/CLANG64 environment
>    - Cross-compilation for Windows on ARM is possible using MSYS2/CLANG64/CLANGARM64
>
> CHANGES
> -------
> * better adherence to c23 standard
> * splot with pm3d fillcolor <x> generates a matching key sample
> * gprintf %H format is distinct from %h in utf8 context
>    - %H uses dot operator between mantissa and exponent
> * kitty, sixel: default size to 100% width, 75% height of terminal window
> * Partially deprecate the "sample" keyword for plot commands.
>    The plot command accepts axis ranges as the first thing after "plot".
>    If present, they update the primary axis ranges x y x2 y2.
>    However if this is preced by the keyword "sample" it refers to a sampling range
>    rather than an axis range.  If a second colon is found in the range,
>    as in [t=min:max:increment], this is unambiguously a sample range so the
>    "sample" keyword is not required.
> * Do not break contour lines into 100-segment fragments.
>    - This fixes a bug when saved contour lines are used as polygons.
>    - To maintain previous placement of contour labels along long contours, use
>    "set cntrlabl interval 100".
>
> FIXES
> -----
> * sixel: improved support for a transparent background
> * kitty: support animation on a transparent background
> * webp:  support animation on a transparent background
> * backport fixes for color assignment to pm3d surfaces
>    - "set pm3d implicit" + "with lines" treated the same as "with pm3d"
>    - adds support for "fc background"
>    - pm3d interpolate > 1 inherits rgb color assignments from the parent tile
> * fill style of colorbox should match fill style of pm3d surface
> * svg: fillstyle solid <frac> was incorrectly treated as transparent
> * transparent fill color in 3D boxes and polygons
> * alpha channel colors on ARM platforms
> * resolve ambiguous syntax in "set dashtype i (n,m)"
> * svg: font size changes within a text fragment could be lost
> * "reset session" must terminate multiplot mode
> * determination of above/below in polar mode filledcurves
> * always flush cached lines from hidden3d if any are present
> * incorrect evaluation of a**b for integer a, integer b < 0
>    in the case that overflow handling has been set to "NaN" or "undefined"
> * loss of precision in some ranges for asin acos asinh acosh
>
>

Re: Backport request for 6.0.4 release version

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

On Tuesday, 9 December 2025 15:20:28 PST sfhm wrote:
> Dear Ethan,
> 
> I would like to request a backport to the 6.0.4 release.
> 
> I have observed differences in polygon color rendering between the
> development version and previous release versions (including
> 6.0.4-testing). The development version renders polygons with the intended
> colors, while the release versions render them with different colors.

[snip example] 

> If the fix for this issue in the development version is sufficiently
> stable, I would greatly appreciate its backport to the 6.0.4 release, even
> if only for some of the cases rather than all of them.

Unfortunately, that is not a trivial change.  

The code that deals with how fill color and border color are specified,
stored, and eventually applied to graphical elements in the plot has
diverged between 6.0 and the development branch.

A partial list of relevant commits in 6.1 that do not apply cleanly to 6.0
	c92721 fc9818 

Nevertheless, it is possible that the specific cases of "splot with polygons"
in your test script could be handled either by some subset of the changes
currently in the development branch or by some ad hoc fixes for 6.0.
The trick is not to break anything else.

I will look into it, but no promises about 6.0.4.  

 Ethan

Re: New warning about inline data and multiplots

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

Good info. Thanks for writing that up! Hopefully I'll get some time to
fix this on my end soon.

Backport request for 6.0.4 release version

[sfhm <sf...@gm...>]

Dear Ethan,

I would like to request a backport to the 6.0.4 release.

I have observed differences in polygon color rendering between the
development version and previous release versions (including
6.0.4-testing). The development version renders polygons with the intended
colors, while the release versions render them with different colors.

The following script demonstrates the issue:
```
set xrange [-2:2]
set yrange [-2:2]
set zrange [-2:2]

$contour <<EOD
-1 -1 0
-1  1 0
 1  1 0
 1 -1 0
-1 -1 0
EOD

set style line 3 lc "#d000ff00"
set key noautotitle
set isotropic
set xyplane 0
set view ,,1.6


set multiplot layout 2,2

  # plot 1 : filled in "Red" with "Blue" border
  set title "Plot 1"
  splot $contour using 1:2:3 with polygons fillstyle border lc "blue" fc
rgb "red"

  # plot 2 : filled in pallete color with default border
  set title "Plot 2"
  splot $contour using 1:2:3 with polygons fillstyle fc palette

  # plot 3 : filled in transparent default color with "Black" border
  set title "Plot 3"
  splot $contour using 1:2:3 with polygons fillstyle transparent border lc
black

  # plot 4 : filled in transparent "Green" color with default border
  set title "Plot 4"
  splot $contour using 1:2:3 with polygons ls 3

unset multiplot

pause -1
```

If the fix for this issue in the development version is sufficiently
stable, I would greatly appreciate its backport to the 6.0.4 release, even
if only for some of the cases rather than all of them.

Thank you for your consideration.

Best regards,
H. Motoyoshi

Re: Pre-release testing version of gnuplot 6.0.4

[Erik L. <eri...@gm...>]

Dear Ethan,

This compiles properly on macOS. I placed a universal binary here (all
libraries statically linked):
https://csml.northwestern.edu/Download/Gnuplot/gnuplot-6.0.4-qt5-universal.pkg,
so that others can test it as well.

I did not compile without mouse support, so I cannot speak to the issue
Achim identified.

Regards,

Erik


On Fri, Dec 5, 2025 at 8:14 PM Ethan A Merritt <me...@uw...> wrote:

> I have placed a testing version of the source release
> package for gnuplot 6.0.4 on the "testing" section of the
> SourceForge download site.
>
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> Nothing major to look for in this release, but it does include a number
> of recent bug fixes. The configure script and various header files
> have been modified to allow use with C compilers that enforce c23
> syntax by default. This should not affect use with older compilers.
>
> My tentative plan is to announce the actual release in about
> two weeks (the week of 15 December).  That can be pushed back
> if you find any problems or want to suggest inclusion
> of a bug-fix from the development version that was not yet
> backported.
>
> Brief release notes below, or see
>      gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html
>
>
>
> %%%%%%%%%%    6.0.4 Release Notes 01-December-2025    %%%%%%%%%%%%%%%%
>
> NEW (back-ported from development version)
> ------------------------------------------
> * variable Inf is pre-set to floating point INFINITY
> * "sharpen" filter handles vertical edges in a step function
> * gprintf format specifiers %C and %Ci
>   - %C  formats a complex value as {a, b}
>       This is the format used by the gnuplot "print" command
>   - %Ci formats a complex value as a + bi
>       Both the real and imaginary parts are printed using libc format %g
>       with optional width and precision
> * Support for Windows on ARM 64-bit architectures
>   - mingw: optionally use the MSYS2/CLANG64 environment
>   - Cross-compilation for Windows on ARM is possible using
> MSYS2/CLANG64/CLANGARM64
>
> CHANGES
> -------
> * better adherence to c23 standard
> * splot with pm3d fillcolor <x> generates a matching key sample
> * gprintf %H format is distinct from %h in utf8 context
>   - %H uses dot operator between mantissa and exponent
> * kitty, sixel: default size to 100% width, 75% height of terminal window
> * Partially deprecate the "sample" keyword for plot commands.
>   The plot command accepts axis ranges as the first thing after "plot".
>   If present, they update the primary axis ranges x y x2 y2.
>   However if this is preced by the keyword "sample" it refers to a
> sampling range
>   rather than an axis range.  If a second colon is found in the range,
>   as in [t=min:max:increment], this is unambiguously a sample range so the
>   "sample" keyword is not required.
> * Do not break contour lines into 100-segment fragments.
>   - This fixes a bug when saved contour lines are used as polygons.
>   - To maintain previous placement of contour labels along long contours,
> use
>   "set cntrlabl interval 100".
>
> FIXES
> -----
> * sixel: improved support for a transparent background
> * kitty: support animation on a transparent background
> * webp:  support animation on a transparent background
> * backport fixes for color assignment to pm3d surfaces
>   - "set pm3d implicit" + "with lines" treated the same as "with pm3d"
>   - adds support for "fc background"
>   - pm3d interpolate > 1 inherits rgb color assignments from the parent
> tile
> * fill style of colorbox should match fill style of pm3d surface
> * svg: fillstyle solid <frac> was incorrectly treated as transparent
> * transparent fill color in 3D boxes and polygons
> * alpha channel colors on ARM platforms
> * resolve ambiguous syntax in "set dashtype i (n,m)"
> * svg: font size changes within a text fragment could be lost
> * "reset session" must terminate multiplot mode
> * determination of above/below in polar mode filledcurves
> * always flush cached lines from hidden3d if any are present
> * incorrect evaluation of a**b for integer a, integer b < 0
>   in the case that overflow handling has been set to "NaN" or "undefined"
> * loss of precision in some ranges for asin acos asinh acosh
>
>
> --
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Pre-release testing version of gnuplot 6.0.4

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

Ethan A Merritt writes:
> I have placed a testing version of the source release
> package for gnuplot 6.0.4 on the "testing" section of the
> SourceForge download site.

There's a missing conditional in unset.c which prevents successful
compilation when mouse support is not enabled.

--8<---------------cut here---------------start------------->8---
--- origsrc/gnuplot-6.0.4/src/unset.c
+++ src/gnuplot-6.0.4/src/unset.c
@@ -2068,8 +2068,10 @@
 	    multiplot_end();
 	init_constants();
 	init_session();
+#ifdef USE_MOUSE
 	reset_mouse();
 	reset_since_last_plot = TRUE;
+#endif
 	return;
     }

@@ -2116,7 +2118,9 @@
      * suppress some of the commentary output by the individual
      * unset_...() routines. */
     interactive = FALSE;
+#ifdef USE_MOUSE
     reset_since_last_plot = TRUE;
+#endif
 
     unset_samples();
     unset_isosamples();

--- origsrc/gnuplot-6.0.4/src/plot2d.c
+++ src/gnuplot-6.0.4/src/plot2d.c
@@ -225,7 +225,9 @@
 	int_error(c_token, "use 'set term' to set terminal type first");
 
     is_3d_plot = FALSE;
+#ifdef USE_MOUSE
     reset_since_last_plot = FALSE;
+#endif
 
     if (parametric && strcmp(set_dummy_var[0], "u") == 0)
 	strcpy(set_dummy_var[0], "t");

--- origsrc/gnuplot-6.0.4/src/plot3d.c
+++ src/gnuplot-6.0.4/src/plot3d.c
@@ -312,7 +312,9 @@
     AXIS_INDEX axis, u_axis, v_axis;
 
     is_3d_plot = TRUE;
+#ifdef USE_MOUSE
     reset_since_last_plot = FALSE;
+#endif
 
     if (parametric && strcmp(set_dummy_var[0], "t") == 0) {
 	strcpy(set_dummy_var[0], "u");

--8<---------------cut here---------------end--------------->8---


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Pre-release testing version of gnuplot 6.0.4

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

I have placed a testing version of the source release
package for gnuplot 6.0.4 on the "testing" section of the
SourceForge download site.

    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

Nothing major to look for in this release, but it does include a number
of recent bug fixes.　The configure script and various header files
have been modified to allow use with C compilers that enforce c23
syntax by default. This should not affect use with older compilers.

My tentative plan is to announce the actual release in about
two weeks (the week of 15 December).  That can be pushed back
if you find any problems or want to suggest inclusion
of a bug-fix from the development version that was not yet
backported.

Brief release notes below, or see 
     gnuplot.sourceforge.net/ReleaseNotes_6_0_4.html



%%%%%%%%%%    6.0.4 Release Notes 01-December-2025    %%%%%%%%%%%%%%%%

NEW (back-ported from development version)
------------------------------------------
* variable Inf is pre-set to floating point INFINITY
* "sharpen" filter handles vertical edges in a step function
* gprintf format specifiers %C and %Ci
  - %C  formats a complex value as {a, b}
      This is the format used by the gnuplot "print" command
  - %Ci formats a complex value as a + bi
      Both the real and imaginary parts are printed using libc format %g
      with optional width and precision
* Support for Windows on ARM 64-bit architectures
  - mingw: optionally use the MSYS2/CLANG64 environment
  - Cross-compilation for Windows on ARM is possible using MSYS2/CLANG64/CLANGARM64

CHANGES
-------
* better adherence to c23 standard
* splot with pm3d fillcolor <x> generates a matching key sample
* gprintf %H format is distinct from %h in utf8 context
  - %H uses dot operator between mantissa and exponent
* kitty, sixel: default size to 100% width, 75% height of terminal window
* Partially deprecate the "sample" keyword for plot commands.
  The plot command accepts axis ranges as the first thing after "plot".
  If present, they update the primary axis ranges x y x2 y2.
  However if this is preced by the keyword "sample" it refers to a sampling range
  rather than an axis range.  If a second colon is found in the range,
  as in [t=min:max:increment], this is unambiguously a sample range so the
  "sample" keyword is not required.
* Do not break contour lines into 100-segment fragments.
  - This fixes a bug when saved contour lines are used as polygons.
  - To maintain previous placement of contour labels along long contours, use
  "set cntrlabl interval 100".

FIXES
-----
* sixel: improved support for a transparent background
* kitty: support animation on a transparent background
* webp:  support animation on a transparent background
* backport fixes for color assignment to pm3d surfaces
  - "set pm3d implicit" + "with lines" treated the same as "with pm3d"
  - adds support for "fc background"
  - pm3d interpolate > 1 inherits rgb color assignments from the parent tile
* fill style of colorbox should match fill style of pm3d surface
* svg: fillstyle solid <frac> was incorrectly treated as transparent
* transparent fill color in 3D boxes and polygons
* alpha channel colors on ARM platforms
* resolve ambiguous syntax in "set dashtype i (n,m)"
* svg: font size changes within a text fragment could be lost
* "reset session" must terminate multiplot mode
* determination of above/below in polar mode filledcurves
* always flush cached lines from hidden3d if any are present
* incorrect evaluation of a**b for integer a, integer b < 0
  in the case that overflow handling has been set to "NaN" or "undefined"
* loss of precision in some ranges for asin acos asinh acosh


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

Re: New warning about inline data and multiplots

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

On Thursday, 4 December 2025 00:12:07 PST Dima Kogan wrote:

> Thanks for the notes!
> 
> I'll try to make this change when I get the time. What would work better
> if I use the datablock? 

Well, multiplot would work :-)
Seiously, your script works fine either with input from '-' or from
a datablock so long as it isn't inside a multiplot.

> Does that work with older gnuplot also?

It works in version 5.   (5.0 5.2 5.4)

> > The output script, as attached, was also incorrect in that it did not
> > contain an "unset multiplot" command.
> 
> OK. It was never clear to me if that was required, and what, if
> anything, was broken by omitting it.

The multiplot is not fully defined until the "unset multiplot" is reached.

One major thing is that most multiplots change the plot boundaries and
screen layout.  The original boundaries are restored by "unset multiplot".

Another is that in version 6, when the program sees a  "set multiplot"
command it begins saving commands into a datablock of strings named
$GPVAL_LAST_MULTIPLOT.  It continues saving commands into that block
until the "unset multiplot" command is reached.  That allows the entire
multiplot to be reproduced by replaying the saved commands.
That in turn allows "replot" to work, and to some extent mousing/zoom/pan,
none of which was possible at all prior to version 6.  This is the change that
rules out supporting use of plot '-' inside a multiplot, since the data cannot
be parsed or executed as valid gnuplot commands.

[aside] According to the documentation another concern is that some
terminals do not produce any visible output until the "unset" command.
I don't think that is true for any current terminals, so that particular
warning may be out of date. 

> 
> > For that matter, I don't think the script should be using multiplot at
> > all. Why is it using multiplot? There was nothing in the input you
> > showed that requested multiplot.
> 
> I cut down the demo script, which ended up removing the actual
> "multiplot" part of this. The full script and plot are on the gnuplotlib
> demo page (towards the end):

Ah. And there is the polar mode plot you filed a bug report for.

- Ethan

Re: New warning about inline data and multiplots

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

Thanks for the notes!

I'll try to make this change when I get the time. What would work better
if I use the datablock? Does that work with older gnuplot also?

> The output script, as attached, was also incorrect in that it did not
> contain an "unset multiplot" command.

OK. It was never clear to me if that was required, and what, if
anything, was broken by omitting it.


> For that matter, I don't think the script should be using multiplot at
> all. Why is it using multiplot? There was nothing in the input you
> showed that requested multiplot.

I cut down the demo script, which ended up removing the actual
"multiplot" part of this. The full script and plot are on the gnuplotlib
demo page (towards the end):

  https://github.com/dkogan/gnuplotlib/blob/master/guide/guide.org

Thanks.

Re: Japanese help file on Windows

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

shige 12/04 2025
----------------

Thanks for your advice. Now I can see contents of the right part
correctly (in Japanese). I think the file wgnuplot-ja-utf8.chm 
has no problems on japanese windows pc.


bma...@we... wrote:
| Thank you for checking! I had the same experience with the file 
| downloaded from SF at first. I think the problem is related to Windows' 
| safety "feature" for files downloaded from the internet. You have to 
| make sure to mark the file as "trusted" permanently by (un)ticking the 
| box in the dialog which pops up when you open the file. If the UTF-8 
| encoding should not work on a Japanese PC, you should really see 
| "gibberish" on the panels on the right hand side.
| 
|   Bastian
| 
| 
| Am 04.12.2025 um 00:57 schrieb Shigeharu TAKENO:
| > shige 12/04 2025
| > ---------------
| >
| > I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11
| > PC (japanese environment). But the right part (help content) is
| > not displayed though the left part (section title) is displayed
| > correctly in Japanese.
| >
| > +========================================================+
| >   Shigeharu TAKENO     NIigata Institute of Technology
| >                         kashiwazaki,Niigata 945-1195 JAPAN
| >   sh...@ie...   TEL(&FAX): +81-257-22-8161
| > +========================================================+
| 

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

Re: Japanese help file on Windows

[Bastian M. <bma...@we...>]

Thank you for checking! I had the same experience with the file 
downloaded from SF at first. I think the problem is related to Windows' 
safety "feature" for files downloaded from the internet. You have to 
make sure to mark the file as "trusted" permanently by (un)ticking the 
box in the dialog which pops up when you open the file. If the UTF-8 
encoding should not work on a Japanese PC, you should really see 
"gibberish" on the panels on the right hand side.

   Bastian


Am 04.12.2025 um 00:57 schrieb Shigeharu TAKENO:
> shige 12/04 2025
> ---------------
>
> I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11
> PC (japanese environment). But the right part (help content) is
> not displayed though the left part (section title) is displayed
> correctly in Japanese.
>
> +========================================================+
>   Shigeharu TAKENO     NIigata Institute of Technology
>                         kashiwazaki,Niigata 945-1195 JAPAN
>   sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Japanese help file on Windows

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

shige 12/04 2025
---------------

I downloaded wgnuplot-ja-utf8.chm and opened it on my Windows11 
PC (japanese environment). But the right part (help content) is
not displayed though the left part (section title) is displayed
correctly in Japanese.

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

Re: New warning about inline data and multiplots

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

On Wed, Dec 3, 2025 at 9:02 AM Dima Kogan <gn...@di...>
wrote:

>
> I just ran the gnuplotlib unit test, and I see lots of warnings with one
> of the tests. The plots are still made, but there's A LOT of console
> chatter now:
>
>   "/tmp/tst.gp" line 17: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 18: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 19: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 20: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>   "/tmp/tst.gp" line 21: warning: Reading from '-' inside a multiplot not
> supported; use a datablock instead
>
> This keeps repeating many times.

The resulting gnuplot script is attached. It clearly shows the warnings.
>
> What isn't supported here?


Exactly what it says.  The current (since version 6.0) implementation of
multiplot does not support placing inline data inside a multiplot block.
This is because the full set of commands inside `set multiplot .... unset
multiplot` is saved for replay during mousing or by a replot command, and
inline data would mess that up badly.


> I've been doing this for years with great
> success, and it appears to still work today.


It does not work today.  What you see is the first execution, with a
warning, while it is reading in the multiplot block. But it does not become
part of the multiplot and the program fails to exit the block cleanly.


> Should I be doing something different?

Yes.

$DATA << EOD
line 1
line 2
...
line N
EOD

set multiplot
plot $DATA with lp
unset multiplot


I use gnuplot constantly, every day. But 99% of my usage is
> either through feedgnuplot or gnuplotlib, both of which use inline data.
> Should those tools be using a datablock? Can they?
>

For use with gnuplot version 6 they should.

The output script, as attached, was also incorrect in that it did not
contain an "unset multiplot" command.  For that matter, I don't think the
script should be using multiplot at all.  Why is it using multiplot?  There
was nothing in the input you showed that requested multiplot.  If "set
multiplot" appears in the output gnuplot script I think that must be a bug
in the program that generated the script.

   Ethan

New warning about inline data and multiplots

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

Hello.

I just ran the gnuplotlib unit test, and I see lots of warnings with one
of the tests. The plots are still made, but there's A LOT of console
chatter now:

  "/tmp/tst.gp" line 17: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 18: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 19: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 20: warning: Reading from '-' inside a multiplot not supported; use a datablock instead
  "/tmp/tst.gp" line 21: warning: Reading from '-' inside a multiplot not supported; use a datablock instead

This keeps repeating many times. Cut-down python script:

  import numpy as np
  import gnuplotlib as gp

  xx,yy = np.meshgrid(np.linspace(-5,5,20),
                      np.linspace(-5,5,20))
  zz0 = np.sin(xx) + yy*yy/8.
  gp.plot3d( (zz0,
              dict(_set = ( 'origin 0,0',
                            'size 1,1',
                            'view 60,20,1,1',
                            'xrange [0:20]',
                            'yrange [0:20]',
                            'zrange [0:10]',
                            'contour base',
                            'xyplane at 10',))),
             tuplesize=3,
             _with = 'lines nosurface',
             square=1,
             wait=True,
             hardcopy='/tmp/tst.gp',
             ascii=True,
             multiplot=True)

The resulting gnuplot script is attached. It clearly shows the warnings.

What isn't supported here? I've been doing this for years with great
success, and it appears to still work today. Should I be doing something
different? I use gnuplot constantly, every day. But 99% of my usage is
either through feedgnuplot or gnuplotlib, both of which use inline data.
Should those tools be using a datablock? Can they?

Thanks.

Japanese help file on Windows

[Bastian M. <bma...@we...>]

Hi,

Currently the CHM windows help file in Japanese is encoded in SHIFT-JIS. 
Since the English version is using UTF-8 on the other hand, this should 
also be fine for the Japanese variant. I would appreciate feedback, if 
the wgnuplot-ja-utf8.chm file on SF in the testing/ directory also works 
fine for others.

   Bastian

Re: Request for official gnuplot support on Windows ARM64

[Erik L. <eri...@gm...>]

Dear Ethan,

Apologies for overlooking this message! I am not an expert on Windows /
ARM64; my focus is on macOS binaries (although indeed for both x86-64 and
ARM64).

Sorry that I cannot be of help.

Kind regards,

Erik


On Fri, Oct 3, 2025 at 2:28 PM Ethan A Merritt <me...@uw...> wrote:

> I am forwarding a offer to help add  ARM64 + Windows support to gnuplot.
> Since those are not areas I deal with, perhaps someone else on the
> developers
> list  (Bastian? Tatsuro? Erik?) can respond to this or suggest how to
> proceed.
>
> If "official support" from our side is out of the question, but they are
> willing
> to prepare and host a contributed binary for public download, we could
> offer
> to add a link on the "Downloads offered by others" section of the gnuplot
> web site.
>
> - Ethan
>
> ----------  Forwarded Message  ----------
>
> Subject: Request for official gnuplot support on Windows ARM64
> Date: Monday, 29 September 2025, 01:52:42 PDT
> From: Mugunthan Selvanayagam <mug...@mu...>
> To: merritt@u.washington.edu <merritt@u.washington.edu>
> CC: Gaurav Goel <gg...@qt...>, Vishnu Vardhan Kasiliya
> Sudarsan <vka...@qt...>, Sumit Sharma <
> ss...@qt...>, Mayank Agrawal <ma...@qt...>, Vinod
> Kumar Sukumar <vin...@mu...>, Thirumalai Nagalingam
> <thi...@mu...>
>
> Hi Merritt
>
> I am Mugundan from MulticoreWare https://multicorewareinc.com, India. We
> are collaborating with Qualcomm on enabling native applications and
> libraries for the Snapdragon X Elite Windows on ARM (WoA) platform.
> During our initial testing, we observed that the x64 Windows GNU Plot
> installer fails on Windows ARM64 due to x64-only restrictions. By making a
> minor modification to the Inno Setup installer script, we were able to
> rebuild the installer to function correctly under x64 emulation on Windows
> ARM devices. We would like to upstream this change so that users on Windows
> on ARM can run GNU Plot via emulation. This would immediately make GNU Plot
> accessible to a broader set of Windows ARM64 users and benefit the user
> community.
>
> We also noticed the availability of initial ARM64 test binaries, and we
> would like to know if there is any information regarding the estimated
> timeline for an official release. If there are any blockers, our team would
> be happy to assist and contribute patches to support both the installer and
> native ARM64 builds. Having an official Windows ARM64 support for GNU Plot
> would be a valuable addition for this growing platform, and we would be
> glad to contribute toward making it possible.
>
> Best regards,
>
> Mugundan
>
> MulticoreWare, India
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>