gnuplot-beta Mailing List for gnuplot

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

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

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
>
>
>

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

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
>
>

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

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

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

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
>

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

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

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

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.

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
+========================================================+

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

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
+========================================================+

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

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.

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

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: [email protected] <[email protected]>
> 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
>

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: [email protected] <[email protected]>
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

It does include subdomain 😁

I have DNS in Hover and I don't think I pay anything beyond the domains.
I'll have to look into what I did with test -- it's so long since I set it
up. I removed the AAAA record on the main domain for now. That shouldn't be
giving a cert error no matter what -- it'll either work or not.

Years ago I had this janky setup with the AAAA pointing to a server I had
at VT that got a daily rsync. Definitely not tls friendly, but it gave us
IPv6 and actually performed a lot better than SF. But that setup is long
gone. I was thinking SF had a legit IPv6 service and that's what I
configured, but that was at least a few years ago.

I think I'll have some time this weekend to unpack all that and remind
myself how this was supposed to work. SF not having IPv6 in 2025 is pretty
inexcusable, but then they're up there with GitHub.... Again, I seem to
recall they had an IPv6 approach a few years ago when I set it up but I'll
refresh my memory. In the meantime I've (begrudgingly) removed the AAAA.

But as far as the domain, yes I've prepaid 10 years (I think it's actually
renewed once)...

Cheers
--ckg

Clark Gaylord
cla...@gm...

On Thu, Sep 11, 2025, 14:12 Ethan A Merritt <me...@uw...> wrote:

> On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote:
> > The plot thickens.
> >
> > I wanted to check on crt.sh (a certificate search facility) what certs
> > were issued for gnuplot.info in the past. To my surprise, I didn't find
> > any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
> > for which a certificate was issued first on 2024-03-02 and renewed ever
> > since. And indeed, test.gnuplot.info does work with https.
> >
> > I did not know that this domain exists. Should it?
> > Peter
>
>
> I think Clark Gaylord may be the best, if not the only, person to answer
> this.
> (CC'ed on this reply).
>
> Clark said last month that the gnuplot.info domain was set up
> "on ten year pre payment with auto renew".
> I don't know whether that includes subdomains or not.
> Please excuse my ignorance.  I don't even know what a "certificate" means
> in this context, or how it fits in with domain registration.
>
> Anyhow, sourceforge supprt has acknowledged the request I made to
> them to enable https for gnuplot.info so that may yet take care of it.
> If there is something else I should ask them for, please let me know.
>
>  Ethan
>
>
> > On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> > > Thanks for the pointers.
> > >
> > > After poking around in the SourceForge admin pages I found a place to
> > > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> > > already listed there. That same page states that https access can be
> > > enabled by request, so I placed a support request with the
> > > SourceForge site itself to enable https access via gnuplot.info and
> > > www.gnuplot.info.  We'll see what happens.
> > >
> > > Support tracker:
> > >      https://sourceforge.net/p/forge/site-support/27031/
> > >  Ethan
>
>
> > >
> > > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> > > <moj...@gm...> wrote:
> > > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > > > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > > > the certificate required to serve the site over HTTPS
> > > > ZjQcmQRYFpfptBannerStart
> > > >
> > > >
> > > >
> > > > This Message Is From an Untrusted Sender
> > > >
> > > > You have not previously corresponded with this sender.
> > > >
> > > > See https://itconnect.uw.edu/email-tags  for additional information.
> > > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > > > for assistance.
> > > >
> > > >
> > > >
> > > >
> > > > ZjQcmQRYFpfptBannerEnd
> > > >
> > > >
> > > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > > > wrote:
> > > > >
> > > > >
> > > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > > > <pet...@gm...> wrote:
> > > > > >
> > > > > > The error message means that the certificate required to serve
> > > > > > the site over HTTPS is not valid for the domain name
> > > > > > gnuplot.info [1] (nor
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$
> [2]). If you look at the
> > > > > > certificate (offered by Firefox next to the error message), you
> > > > > > can see that it was issued by Let's Encrypt to
> > > > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > > > selection of other domain names, presumably all projects hosted
> > > > > > by SF.
> > > > > >
> > > > >
> > > > >
> > > > > Thank you for your insights.
> > > > >
> > > > > I think you are addressing a different issue - whether the
> > > > > connection protocol is https or http.
> > > >
> > > > Yes, this is not about DNS failure. I don't experience DNS failure,
> > > > but see precisely the same errors/issues as Peter described.
> > > >
> > > > (Nowadays http should actually redirect to https. Modern browsers
> > > > also refuse to show http pages.)
> > > >
> > > > > It is not surprising that a certificate issued to SourceForge
> > > > > would not mention gnuplot.info [1] by name because that name is
> > > > > not connected to SourceForge except in that (as I understand it)
> > > > > it currently redirects queries to the actual gnuplot site
> > > > > gnuplot.sourceforge.net [4].
> > > >
> > > > Except that it does matter for https. The hosting site needs to
> > > > know that the certificate should also be for gnuplot.info [1]  and
> > > > it needs to be explicit whether that is with or without www (or
> > > > both).
> > > > Either a separate certificate is needed for that, or the
> > > > certificate used needs to be made aware that it needs to cover
> > > > gnuplot.info [1]. This really needs to be fixed on the hosting
> > > > site, and usually the person in charge of the DNS is also needed in
> > > > the process of making it work.
> > > >
> > > > Unless the administrators of gnuplot on SF have access to
> > > > certificate settings (means you would also need to create and
> > > > extend your own certificate), then SF support is really needed here
> > > > to set it up.
> > > >
> > > > > The current problem seems to be that the redirection itself fails
> > > > > in some cases, or fails to pass through sufficient information
> > > >
> > > > No. It's really a misconfigured site/certificate.
> > > >
> > > > > You still see the site, correct?
> > > >
> > > > Well ... yes and no, but the more correct answer is probably NO. By
> > > > default you don't see the site because the web browser is
> > > > protecting you from "the malicious site" until you approve an
> > > > exception and security risk, but that is "an advanced use" (it is
> > > > on purpose made difficult to do that).
> > > >
> > > > > For completeness I should mention that the issue of connection
> > > > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > > > relevant,
> > > >
> > > > It is possible that the site works correctly on IPv4 and fails with
> > > > IPv6. My network right now doesn't support IPv6, so it's hard for
> > > > me to check. It is unrelated to certificate issues, but it could
> > > > hypothetically explain why DNS works for others and not for you if
> > > > you have IPv6. (By correctly I mean resolving to the correct
> > > > website. It still doesn't serve a compliant certificate.)
> > > >
> > > > Mojca
> > > >
> > >
> > >
> >
> >
> > [1] gnuplot.info
> >
> https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
> > [2]
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$
> >
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
> > [3] secureprojects.sourceforge.net
> >
> https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
> > [4] gnuplot.sourceforge.net
> >
> https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$
> >
>
>
> --
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
>
>
>

On 2025-09-11 01:18, Mojca Miklavec Groenhuis wrote:

> (Nowadays http should actually redirect to https. Modern
> browsers also refuse to show http pages.)

While that is sensible for external websites, it needs to be
configurable, so that one can login to admin interfaces on
network routers etc.

-- 
Jeremy Nicoll - my opinions are my own

On Thursday, 11 September 2025 10:08:31 PDT Juhász Péter wrote:
> The plot thickens.
> 
> I wanted to check on crt.sh (a certificate search facility) what certs
> were issued for gnuplot.info in the past. To my surprise, I didn't find
> any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
> for which a certificate was issued first on 2024-03-02 and renewed ever
> since. And indeed, test.gnuplot.info does work with https.
> 
> I did not know that this domain exists. Should it?
> Peter


I think Clark Gaylord may be the best, if not the only, person to answer this.
(CC'ed on this reply).

Clark said last month that the gnuplot.info domain was set up
"on ten year pre payment with auto renew".
I don't know whether that includes subdomains or not.
Please excuse my ignorance.  I don't even know what a "certificate" means
in this context, or how it fits in with domain registration.  

Anyhow, sourceforge supprt has acknowledged the request I made to
them to enable https for gnuplot.info so that may yet take care of it.
If there is something else I should ask them for, please let me know.

 Ethan


> On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> > Thanks for the pointers. 
> > 
> > After poking around in the SourceForge admin pages I found a place to
> > set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> > already listed there. That same page states that https access can be
> > enabled by request, so I placed a support request with the
> > SourceForge site itself to enable https access via gnuplot.info and
> > www.gnuplot.info.  We'll see what happens.
> > 
> > Support tracker:
> >      https://sourceforge.net/p/forge/site-support/27031/
> >  Ethan


> > 
> > On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> > <moj...@gm...> wrote:
> > > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > > the certificate required to serve the site over HTTPS
> > > ZjQcmQRYFpfptBannerStart
> > > 
> > > 
> > > 
> > > This Message Is From an Untrusted Sender 
> > > 
> > > You have not previously corresponded with this sender. 
> > > 
> > > See https://itconnect.uw.edu/email-tags  for additional information.
> > > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > > for assistance. 
> > > 
> > > 
> > >  
> > > 
> > > ZjQcmQRYFpfptBannerEnd
> > > 
> > > 
> > > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > > wrote:
> > > > 
> > > > 
> > > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > > <pet...@gm...> wrote:
> > > > > 
> > > > > The error message means that the certificate required to serve
> > > > > the site over HTTPS is not valid for the domain name
> > > > > gnuplot.info [1] (nor https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$  [2]). If you look at the
> > > > > certificate (offered by Firefox next to the error message), you
> > > > > can see that it was issued by Let's Encrypt to
> > > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > > selection of other domain names, presumably all projects hosted
> > > > > by SF. 
> > > > > 
> > > > 
> > > > 
> > > > Thank you for your insights.
> > > > 
> > > > I think you are addressing a different issue - whether the
> > > > connection protocol is https or http.
> > > 
> > > Yes, this is not about DNS failure. I don't experience DNS failure,
> > > but see precisely the same errors/issues as Peter described.
> > > 
> > > (Nowadays http should actually redirect to https. Modern browsers
> > > also refuse to show http pages.)
> > > 
> > > > It is not surprising that a certificate issued to SourceForge
> > > > would not mention gnuplot.info [1] by name because that name is
> > > > not connected to SourceForge except in that (as I understand it)
> > > > it currently redirects queries to the actual gnuplot site
> > > > gnuplot.sourceforge.net [4].
> > > 
> > > Except that it does matter for https. The hosting site needs to
> > > know that the certificate should also be for gnuplot.info [1]  and
> > > it needs to be explicit whether that is with or without www (or
> > > both).
> > > Either a separate certificate is needed for that, or the
> > > certificate used needs to be made aware that it needs to cover
> > > gnuplot.info [1]. This really needs to be fixed on the hosting
> > > site, and usually the person in charge of the DNS is also needed in
> > > the process of making it work.
> > > 
> > > Unless the administrators of gnuplot on SF have access to
> > > certificate settings (means you would also need to create and
> > > extend your own certificate), then SF support is really needed here
> > > to set it up. 
> > > 
> > > > The current problem seems to be that the redirection itself fails
> > > > in some cases, or fails to pass through sufficient information
> > > 
> > > No. It's really a misconfigured site/certificate.
> > > 
> > > > You still see the site, correct?
> > > 
> > > Well ... yes and no, but the more correct answer is probably NO. By
> > > default you don't see the site because the web browser is
> > > protecting you from "the malicious site" until you approve an
> > > exception and security risk, but that is "an advanced use" (it is
> > > on purpose made difficult to do that).
> > > 
> > > > For completeness I should mention that the issue of connection
> > > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > > relevant,
> > > 
> > > It is possible that the site works correctly on IPv4 and fails with
> > > IPv6. My network right now doesn't support IPv6, so it's hard for
> > > me to check. It is unrelated to certificate issues, but it could
> > > hypothetically explain why DNS works for others and not for you if
> > > you have IPv6. (By correctly I mean resolving to the correct
> > > website. It still doesn't serve a compliant certificate.)
> > > 
> > > Mojca
> > > 
> > 
> > 
> 
> 
> [1] gnuplot.info
>     https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
> [2] https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!gtNM2Sc78gL-Ysg1zk84my1iRsUDO5YKxseY7vQ_6VDym0S2hHL0HhcytN_F1Emi3Mk6-vt_iZU8RIDoRuWGjXY$ 
>     https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
> [3] secureprojects.sourceforge.net
>     https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
> [4] gnuplot.sourceforge.net
>     https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$
> 


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

The plot thickens.

I wanted to check on crt.sh (a certificate search facility) what certs
were issued for gnuplot.info in the past. To my surprise, I didn't find
any. However, they list test.gnuplot.info (and www.test.gnuplot.info)
for which a certificate was issued first on 2024-03-02 and renewed ever
since. And indeed, test.gnuplot.info does work with https.

I did not know that this domain exists. Should it?

Peter

On Wed, 2025-09-10 at 20:17 -0700, Ethan A Merritt wrote:
> Thanks for the pointers. 
> 
> After poking around in the SourceForge admin pages I found a place to
> set up "virtual domains". Both gnuplot.info and www.gnuplot.info are
> already listed there. That same page states that https access can be
> enabled by request, so I placed a support request with the
> SourceForge site itself to enable https access via gnuplot.info and
> www.gnuplot.info.  We'll see what happens.
> 
> https://sourceforge.net/p/forge/site-support/27031/
> 
>  Ethan
> 
> On Wed, Sep 10, 2025 at 5:18 PM Mojca Miklavec Groenhuis
> <moj...@gm...> wrote:
> > On Thu, 11 Sept 2025, 00: 45 Ethan A Merritt, <merritt@ uw. edu>
> > wrote: On Wed, Sep 10, 2025 at 11: 35 AM Juhász Péter
> > <peter. juhasz83@ gmail. com> wrote: The error message means that
> > the certificate required to serve the site over HTTPS
> > ZjQcmQRYFpfptBannerStart
> > 
> > 
> > 
> > This Message Is From an Untrusted Sender 
> > 
> > You have not previously corresponded with this sender. 
> > 
> > See https://itconnect.uw.edu/email-tags for additional information.
> > Please contact the UW-IT Service Center, he...@uw... 206.221.5000,
> > for assistance. 
> > 
> > 
> >  
> > 
> > ZjQcmQRYFpfptBannerEnd
> > 
> > 
> > On Thu, 11 Sept 2025, 00:45 Ethan A Merritt, <me...@uw...>
> > wrote:
> > > 
> > > 
> > > On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter
> > > <pet...@gm...> wrote:
> > > > 
> > > > The error message means that the certificate required to serve
> > > > the site over HTTPS is not valid for the domain name
> > > > gnuplot.info [1] (nor www.gnuplot.info [2]). If you look at the
> > > > certificate (offered by Firefox next to the error message), you
> > > > can see that it was issued by Let's Encrypt to
> > > > secureprojects.sourceforge.net [3], and it is valid for a large
> > > > selection of other domain names, presumably all projects hosted
> > > > by SF. 
> > > > 
> > > 
> > > 
> > > Thank you for your insights.
> > > 
> > > I think you are addressing a different issue - whether the
> > > connection protocol is https or http.
> > 
> > Yes, this is not about DNS failure. I don't experience DNS failure,
> > but see precisely the same errors/issues as Peter described.
> > 
> > (Nowadays http should actually redirect to https. Modern browsers
> > also refuse to show http pages.)
> > 
> > > It is not surprising that a certificate issued to SourceForge
> > > would not mention gnuplot.info [1] by name because that name is
> > > not connected to SourceForge except in that (as I understand it)
> > > it currently redirects queries to the actual gnuplot site
> > > gnuplot.sourceforge.net [4].
> > 
> > Except that it does matter for https. The hosting site needs to
> > know that the certificate should also be for gnuplot.info [1]  and
> > it needs to be explicit whether that is with or without www (or
> > both).
> > Either a separate certificate is needed for that, or the
> > certificate used needs to be made aware that it needs to cover
> > gnuplot.info [1]. This really needs to be fixed on the hosting
> > site, and usually the person in charge of the DNS is also needed in
> > the process of making it work.
> > 
> > Unless the administrators of gnuplot on SF have access to
> > certificate settings (means you would also need to create and
> > extend your own certificate), then SF support is really needed here
> > to set it up. 
> > 
> > > The current problem seems to be that the redirection itself fails
> > > in some cases, or fails to pass through sufficient information
> > 
> > No. It's really a misconfigured site/certificate.
> > 
> > > You still see the site, correct?
> > 
> > Well ... yes and no, but the more correct answer is probably NO. By
> > default you don't see the site because the web browser is
> > protecting you from "the malicious site" until you approve an
> > exception and security risk, but that is "an advanced use" (it is
> > on purpose made difficult to do that).
> > 
> > > For completeness I should mention that the issue of connection
> > > via IPv6 as opposed to IPv4 was raised earlier, and might be
> > > relevant,
> > 
> > It is possible that the site works correctly on IPv4 and fails with
> > IPv6. My network right now doesn't support IPv6, so it's hard for
> > me to check. It is unrelated to certificate issues, but it could
> > hypothetically explain why DNS works for others and not for you if
> > you have IPv6. (By correctly I mean resolving to the correct
> > website. It still doesn't serve a compliant certificate.)
> > 
> > Mojca
> > 
> 
> 
> -- 
> 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


[1] gnuplot.info
    https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$
[2] www.gnuplot.info
    https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$
[3] secureprojects.sourceforge.net
    https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$
[4] gnuplot.sourceforge.net
    https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$