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

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
>

Fwd: Request for official gnuplot support on Windows ARM64

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

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

Re: gnuplot.info unreachable (test.gnuplot.info?)

[Clark G. <cla...@gm...>]

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

Re: gnuplot.info unreachable (DNS failure)

[Jeremy N. - ml g. <jn....@wi...>]

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

Re: gnuplot.info unreachable (test.gnuplot.info?)

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

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

Re: gnuplot.info unreachable (test.gnuplot.info?)

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

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

Re: gnuplot.info unreachable (DNS failure)

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

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
>>> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
>>> (nor www.gnuplot.info
>>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
>>> 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
>>> <https://urldefense.com/v3/__http://secureprojects.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODadFrph0$>,
>>> 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
>> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
>> 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
>> <https://urldefense.com/v3/__http://gnuplot.sourceforge.net__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODckxZJT_$>
>> .
>>
>
> Except that it does matter for https. The hosting site needs to know that
> the certificate should also be for gnuplot.info
> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>
> 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
> <https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!koofFjCmBlGlxmtOCelbImz1v5loEhcR-xo6w0JLq8fvwUwklPYjMJSMeOq-e-_jCe9wWKl4ZSgERWeODc4D2Pme$>.
> 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

Re: gnuplot.info unreachable (DNS failure)

[Mojca M. G. <moj...@gm...>]

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 (nor
>> www.gnuplot.info
>> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
>> 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, 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 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.
>

Except that it does matter for https. The hosting site needs to know that
the certificate should also be for gnuplot.info  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. 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

>

Re: gnuplot.info unreachable (DNS failure)

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

On Wed, Sep 10, 2025 at 11:35 AM Juhász Péter <pet...@gm...>
wrote:

> On Wed, 2025-09-10 at 10: 51 -0700, Ethan A Merritt wrote: To the limited
> extent that I understand the error messages that I am seeing, it is not a
> matter of appropriate content on the server. The query is never getting to
> the server because
> ZjQcmQRYFpfptBannerStart
> On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote:
>
> To the limited extent that I understand the error messages that I am
> seeing,
> it is not a matter of appropriate content on the server.  The query is
> never
> getting to the server because some intermediate service provider is
> failing to
> deliver it.  If I am misunderstanding and there is some configuration
> thing I
> can change on the SourceForge end, please let me know.
>
>
> Hi,
>
> you've mentioned that the actual content is hosted on/by SourceForge.
>
> Under what kind of formal or informal arrangement or contract does this
> happen? Was any payment involved
>

No payment or formal contract with SourceForge that I know of.

The error message means that the certificate required to serve the site
> over HTTPS is not valid for the domain name gnuplot.info (nor
> www.gnuplot.info
> <https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hZAtTCSEA3UZsTRDYd1Rlg-J8_Oq7DJZg-cJMaMoMBMcyZx3lwvCVqHE401p-ZikRUWZruc71FaDNhZkYYE3tw4$>).
> 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, 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. It is not surprising that a certificate issued
to SourceForge would not mention gnuplot.info 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.  The current problem seems to be that the
redirection itself fails in some cases, or fails to pass through sufficient
information (or credentials or something - I really really don't understand
this stuff).  If you are seeing an error message that refers to a
SourceForge certificate then I think in your case the redirection must have
succeeded. You still see the site, correct?  It's just that connection is
falling back to http rather that https.

I was getting an error from some intermediary network entity (Cloudflare)
that reports  "DNS resolution error 1001". As Hans-Bernhard noted, that's
rather odd because DNS does seem to work correctly when tested by command
line tools.

For completeness I should mention that the issue of connection via IPv6 as
opposed to IPv4 was raised earlier, and might be relevant, but that goes
way beyond my level of understanding.

   Ethan


> So the person who is responsible for renewing this certificate at SF
> either made a mistake by not including gnuplot.info (and in this case a
> gentle reminder may fix the issue in October at the very latest, possibly
> earlier), or deliberately removed gnuplot.info from the list of domains,
> because the afore-hypothesized contract has expired (in which case the
> gentle reminder may have to include money).
>
> As to whom that gentle reminder should be sent, I have no idea.
>
best regards,
>
> Peter Juhasz
>

Re: gnuplot.info unreachable (DNS failure)

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

On Wed, 2025-09-10 at 10:51 -0700, Ethan A Merritt wrote:
> To the limited extent that I understand the error messages that I am
> seeing,
> it is not a matter of appropriate content on the server.  The query
> is never
> getting to the server because some intermediate service provider is
> failing to
> deliver it.  If I am misunderstanding and there is some configuration
> thing I
> can change on the SourceForge end, please let me know.
> 

Hi,

you've mentioned that the actual content is hosted on/by SourceForge.

Under what kind of formal or informal arrangement or contract does this
happen? Was any payment involved?

The error message means that the certificate required to serve the site
over HTTPS is not valid for the domain name gnuplot.info (nor
www.gnuplot.info). 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, and it is valid for a large
selection of other domain names, presumably all projects hosted by SF.
The certificate is valid between Tue, 29 Jul 2025 02:33:38 GMT and Mon,
27 Oct 2025 02:33:37 GMT.

So the person who is responsible for renewing this certificate at SF
either made a mistake by not including gnuplot.info (and in this case a
gentle reminder may fix the issue in October at the very latest,
possibly earlier), or deliberately removed gnuplot.info from the list
of domains, because the afore-hypothesized contract has expired (in
which case the gentle reminder may have to include money).

As to whom that gentle reminder should be sent, I have no idea.

best regards,

Peter Juhasz

Re: gnuplot.info unreachable (DNS failure)

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

On Wed, Sep 10, 2025 at 5:53 AM Philipp K. Janert via gnuplot-beta <
gnu...@li...> wrote:

> On Tue, 09 Sep 2025 16:19:58 -0700
> Ethan A Merritt <me...@uw...> wrote:
>
>
> I don't want to be a stickler, but I don't
> think changing the docs from "gnuplot.info"
> to "www.gnuplot.info" is really the right
> way to think about it.


[shrug]  That's the only part of it I can do myself, and it takes effect
immediately.
The on-line docs now work again (as seen from here), whereas access was
failing yesterday. I hope someone else can arrange a more global long-term
fix
or at least identify what that fix would be.


> The domain/server should be configured to
> accept both versions and serve the appropriate
> content. That's pretty standard issue, in my
> experience.


To the limited extent that I understand the error messages that I am seeing,
it is not a matter of appropriate content on the server.  The query is never
getting to the server because some intermediate service provider is failing
to
deliver it.  If I am misunderstanding and there is some configuration thing
I
can change on the SourceForge end, please let me know.

   Ethan



Best,
>
>                 Ph.
>



> > On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:
> >
> > > Ethan can't link to gnuplot.info (note: no leading www.).
> >
> > Good point.  I typed the address into the browser directly because
> > Phillipp's reported error message was
> >    "Firefox does not trust this site because it uses a certificate
> > that is not valid for gnuplot.info"
> >
> > > [...] also fails, with a
> > > "DNS resolution error 1001"  reported by Cloudflare.
> > > Which is strange, as tracert did get an IP,  i.e. DNS actually
> > > works.
> >
> > Yes.  That's the one I'm seeing.  It's an internal error message from
> > Cloudflare that I get when I request either
> https://urldefense.com/v3/__http://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxPgQ2mvA$
> or
> >
> https://urldefense.com/v3/__https://gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxK_p5wIQ$
> >
> > It does work if I request
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$
>   (Chrome or
> > Firefox browsers).
> >
> > The hyperlink references in the pdf version of the user manual  use
> > the
> https://urldefense.com/v3/__http://www.gnuplot.info__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lxJY2e2hg$
> form.    But the html versions of the manual use
> > the gnuplot.info form [no www] everywhere.
> >
> > That much I can fix.
> > I will modify the gnuplot.doc inline html tables and the code in
> > doc2web.c to always generate output with the www prefix in the URL.
> >
> > However it is probably a common "mistake" for users to omit the www
> > prefix in web queries since that is no longer as near-universal as it
> > once was.  For that matter Chrome actively hides the "www." prefix
> > when it shows the current site in the bar at the top, so a
> > cut-and-paste may fail to capture the full, working, address.
> >
> >    Ethan
> >
> >
> >
> >
> >
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via:
> >
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!hKklbxAh2wg2JWTINjAGHDtkHTSmzmPsg4w5G1Zu-N3BPWS_Fszt9uVqK6s9gOHUge9KIxOjuZdyCw6GT_4X1lypuFKcMA$
>


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

Re: gnuplot.info unreachable (DNS failure)

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

On Tue, 09 Sep 2025 16:19:58 -0700
Ethan A Merritt <me...@uw...> wrote:

> On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:
> 

I don't want to be a stickler, but I don't 
think changing the docs from "gnuplot.info" 
to "www.gnuplot.info" is really the right
way to think about it. 

The domain/server should be configured to
accept both versions and serve the appropriate
content. That's pretty standard issue, in my
experience.

Best,

		Ph.

> 
> > Ethan can't link to gnuplot.info (note: no leading www.).  
> 
> Good point.  I typed the address into the browser directly because
> Phillipp's reported error message was 
>    "Firefox does not trust this site because it uses a certificate
> that is not valid for gnuplot.info"
>  
> > [...] also fails, with a
> > "DNS resolution error 1001"  reported by Cloudflare. 
> > Which is strange, as tracert did get an IP,  i.e. DNS actually
> > works.  
> 
> Yes.  That's the one I'm seeing.  It's an internal error message from
> Cloudflare that I get when I request either http://gnuplot.info or
> https://gnuplot.info
> 
> It does work if I request http://www.gnuplot.info   (Chrome or
> Firefox browsers).
> 
> The hyperlink references in the pdf version of the user manual  use
> the www.gnuplot.info form.    But the html versions of the manual use
> the gnuplot.info form [no www] everywhere.
> 
> That much I can fix.
> I will modify the gnuplot.doc inline html tables and the code in
> doc2web.c to always generate output with the www prefix in the URL. 
> 
> However it is probably a common "mistake" for users to omit the www
> prefix in web queries since that is no longer as near-universal as it
> once was.  For that matter Chrome actively hides the "www." prefix
> when it shows the current site in the bar at the top, so a
> cut-and-paste may fail to capture the full, working, address.
> 
>    Ethan
> 
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: gnuplot.info unreachable (DNS failure)

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

On Tuesday, 9 September 2025 14:22:58 PDT Hans-Bernhard Bröker wrote:


> Ethan can't link to gnuplot.info (note: no leading www.).

Good point.  I typed the address into the browser directly because Phillipp's 
reported error message was 
   "Firefox does not trust this site because it uses a certificate that is not
     valid for gnuplot.info"
 
> [...] also fails, with a
> "DNS resolution error 1001"  reported by Cloudflare. 
> Which is strange, as tracert did get an IP,  i.e. DNS actually works.

Yes.  That's the one I'm seeing.  It's an internal error message from Cloudflare
that I get when I request either http://gnuplot.info or https://gnuplot.info

It does work if I request http://www.gnuplot.info   (Chrome or Firefox browsers).

The hyperlink references in the pdf version of the user manual  use the
www.gnuplot.info form.    But the html versions of the manual use
the gnuplot.info form [no www] everywhere.

That much I can fix.
I will modify the gnuplot.doc inline html tables and the code in
doc2web.c to always generate output with the www prefix in the URL. 

However it is probably a common "mistake" for users to omit the www prefix in web
queries since that is no longer as near-universal as it once was.  For that matter
Chrome actively hides the "www." prefix when it shows the current site in the bar
at the top, so a cut-and-paste may fail to capture the full, working, address.

   Ethan

Re: gnuplot.info unreachable (DNS failure)

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

Am 09.09.2025 um 19:10 schrieb Ethan A Merritt:
> As of this morning I can't seem to reach gnuplot.info <http:// 
> gnuplot.info> via either http or https.   

We have to be sticklers to detail here to avoid extra confusion.

Philipp had problems accessing www.gnuplot.info via https.

Ethan can't link to gnuplot.info (note: no leading www.).

So I went ahead and tracert'd to both names.  I get an IPv4 address for 
www.gnuplot.info (204.68.111.101), whereas gnuplot.info traces to an 
IPv6 address ([2606:4700:4400::ac40:9691]).

http://www.gnuplot.info via  just works.

https://www.gnuplot.info barfs because the site certificate does not 
report itself as matching the site name.  That kind-a figures, as the 
certificate is from SourceForge, which does host that actual site, but 
not the *.gnuplot.info redirects.

https://gnuplot.info fails with a _different_ problem: neither FireFox 
nor Edge could agree with the server on any cypher algorithm both sides 
allow/support.

http://gnuplot.info also fails, with a "DNS resolution error 1001" 
reported by Cloudflare.  Which is strange, as tracert did get an IP, 
i.e. DNS actually works.

Re: gnuplot.info unreachable (DNS failure)

[Folkert v. H. <fo...@va...>]

>> As of this morning I can't seem to reach gnuplot.info via either http
>> or https.   The similar problems reported here last year and earlier
>> this year did not seem to affect my connection here, so the current
>> issue is either something altogether different or else affects a
>> larger fraction of the CloudFlare network coverage.
>> 
>> Access to the underlying web site on SourceForge is still OK.  It's
>> just the redirection though gnuplot.info that is broken.
> 
> Actually, I can't confirm that. I can reach
> 	http://www.gnuplot.info
> but httpS gives me the error message I posted
> yesterday.
> 
> Is it possible that I have a local DNS cache
> that makes this possible? (Wild, clueless
> speculation...)
> 
> I am located in the East (PA). Regional problem?

Doubt it. Here in the Netherlands (Europe) the problem is the same: 
https://imgpaste.nurd.space/pics/bd60183c8b9f65e72283b63d2f8c95bdb5b33b0835a40305234b9d463a70d83e.png



-- 
www.vanheusden.com

Re: gnuplot.info unreachable (DNS failure)

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

On Tue, 9 Sep 2025 10:10:35 -0700
Ethan A Merritt <me...@uw...> wrote:

> As of this morning I can't seem to reach gnuplot.info via either http
> or https.   The similar problems reported here last year and earlier
> this year did not seem to affect my connection here, so the current
> issue is either something altogether different or else affects a
> larger fraction of the CloudFlare network coverage.
> 
> Access to the underlying web site on SourceForge is still OK.  It's
> just the redirection though gnuplot.info that is broken.

Actually, I can't confirm that. I can reach
	http://www.gnuplot.info 
but httpS gives me the error message I posted
yesterday.

Is it possible that I have a local DNS cache
that makes this possible? (Wild, clueless
speculation...)

I am located in the East (PA). Regional problem?

> 
> - Ethan

gnuplot.info unreachable (DNS failure)

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

As of this morning I can't seem to reach gnuplot.info via either http or
https.   The similar problems reported here last year and earlier this year
did not seem to affect my connection here, so the current issue is either
something altogether different or else affects a larger fraction of the
CloudFlare network coverage.

Access to the underlying web site on SourceForge is still OK.  It's just
the redirection though gnuplot.info that is broken.

- Ethan

httpS problems again?

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

I just tried to go to https://gnuplot.info,
using Firefox, and got an error message. I 
get equivalent errors when using Chromium, 
and for the URL https://www.gnuplot.info

http (no S) is fine.

I don't seem able to attach a screenshot 
when posting to the mailing list, but a
text rendering of the details is below.

I seem to recall that we had a similar 
problem, about a year ago?

Not sure what to do about this - just the 
messenger!

Best,

        Ph.


ERROR DETAILS:

Websites prove their identity via certificates. Firefox does not trust
this site because it uses a certificate that is not valid for
gnuplot.info. The certificate is only valid for the following names:
amanda.org, bluefish.openoffice.nl, code.videlibri.de,
community.jedit.org, extensions.openoffice.org,
extensions.services.openoffice.org, exult.info, freecol.org,
freeplane.org, gnomesubtitles.org, gparted.org, gphoto.com, gphoto.org,
itksnap.org, jedit.org, libpng.com, libpng.org, linuxcommand.org,
net-snmp.org, nsis.io, opencamera.org.uk, openjump.org, openocd.org,
plugins.jedit.org, roundup-tracker.org, sbcl.org,
secureprojects.sourceforge.net, swig.org, synoboost.com,
templates.openoffice.org, templates.services.openoffice.org,
update.apexdc.net, usermin.com, videlibri.de, vswamp.com, webmin.com,
wings3d.com, www.amanda.org, www.bluefish.openoffice.nl,
www.exult.info, www.freecol.org, www.freeplane.org,
www.gnomesubtitles.org, www.gphoto.com, www.gphoto.org,
www.itksnap.org, www.jedit.org, www.libpng.com, www.libpng.org,
www.linuxcommand.org, www.net-snmp.org, www.opencamera.org.uk,
www.openjump.org, www.openocd.org, www.roundup-tracker.org,
www.sbcl.org, www.swig.org, www.synoboost.com, www.usermin.com,
www.videlibri.de, www.vswamp.com, www.webmin.com, www.wings3d.com Error
code: SSL_ERROR_BAD_CERT_DOMAIN 

-- 

Philipp K. Janert
www.janert.me

Test

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

Testing.

In the last 24 hrs, I twice tried to
post to this list, but do not see the
msgs show up. 

They included an attachment, maybe 
that's the problem.

-- 

Philipp K. Janert
www.janert.me

Re: Re: Latex error on recent dev branch

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

Use of lualatex instead of pdflatex solves the issue.
Thanks.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2025/07/19 土 00:28
> Subject: Re: Latex error on recent dev branch
> 
> 
> On Thursday, 17 July 2025 22:51:19 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > I have met the following LaTeX error on the recent dev branch during make pdf.
> > > *********************************************************************
> > > ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> > > (ucs)                possibly declared in uni-33.def.
> > > (ucs)                Type H to see if it is available with options.
> > > 
> > > See the ucs package documentation for explanation.
> > > Type  H <return>  for immediate help.
> > >  ...
> > > 
> > > l.15507 \verb~"\U+2148"~ & A + Bⅈ
> > >                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> > > *********************************************************************
> > > Please give me a hint to overcome this.
> 
> Version 6.0.3 Release Notes
> 
> - TeXLive2024 pdflatex does not like some of the UTF-8 characters in the user manual.
>   The distribution includes a pre-built copy of gnuplot.pdf but if you want
>   to rebuild it from the source in docs/gnuplot.doc please use lualatex instead.
>   You can either replace the definition PDFLATEX=pdflatex with PDFLATEX=lualatex
>   in the Makefile or provide this in the environment during configuration
>         PDFLATEX=lualatex ./configure
> 
> The Makefile already requires lualex for the Japanese documentation.
> Maybe it is time to require it also for the English documentation.
> 
>  Ethan
> 
> > > ----- Original Message -----
> > > 
> > > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > > To: "beta" <gnu...@li...>
> > > Date: 2025/07/18 金 09:10
> > > Subject: Latex error on recent dev branch
> > > 
> > > 
> > > I have met the following LaTeX error on the recent dev branch. 
> > > *********************************************************************
> > > ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> > > (ucs)                possibly declared in uni-33.def.
> > > (ucs)                Type H to see if it is available with options.
> > > 
> > > See the ucs package documentation for explanation.
> > > Type  H <return>  for immediate help.
> > >  ...
> > > 
> > > l.15507 \verb~"\U+2148"~ & A + Bⅈ
> > >                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> > > *********************************************************************
> > > Please give me a hint to overcome this.
> > > 
> > > Tatsuro
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > gnuplot-beta mailing list
> > > gnu...@li...
> > > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!ntDJkCbntUyvtjWACoyKxH33sOtgd2BWTy1sKBUr_PfkMeekvnd8fMKcYnq4T9tDitajZAx-6eNDbB7hfSIBopb4f9YyZA$ 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!ntDJkCbntUyvtjWACoyKxH33sOtgd2BWTy1sKBUr_PfkMeekvnd8fMKcYnq4T9tDitajZAx-6eNDbB7hfSIBopb4f9YyZA$ 
> > 
> 
> 
> -- 
> Ethan A Merritt
> Department of Biochemistry
> University of Washington, Seattle
> 
> 

Re: Latex error on recent dev branch

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

On Thursday, 17 July 2025 22:51:19 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> I have met the following LaTeX error on the recent dev branch during make pdf.
> > *********************************************************************
> > ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> > (ucs)                possibly declared in uni-33.def.
> > (ucs)                Type H to see if it is available with options.
> > 
> > See the ucs package documentation for explanation.
> > Type  H <return>  for immediate help.
> >  ...
> > 
> > l.15507 \verb~"\U+2148"~ & A + Bⅈ
> >                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> > *********************************************************************
> > Please give me a hint to overcome this.

Version 6.0.3 Release Notes

- TeXLive2024 pdflatex does not like some of the UTF-8 characters in the user manual.
  The distribution includes a pre-built copy of gnuplot.pdf but if you want
  to rebuild it from the source in docs/gnuplot.doc please use lualatex instead.
  You can either replace the definition PDFLATEX=pdflatex with PDFLATEX=lualatex
  in the Makefile or provide this in the environment during configuration
        PDFLATEX=lualatex ./configure

The Makefile already requires lualex for the Japanese documentation.
Maybe it is time to require it also for the English documentation.

 Ethan

> > ----- Original Message -----
> > 
> > From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> > To: "beta" <gnu...@li...>
> > Date: 2025/07/18 金 09:10
> > Subject: Latex error on recent dev branch
> > 
> > 
> > I have met the following LaTeX error on the recent dev branch. 
> > *********************************************************************
> > ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> > (ucs)                possibly declared in uni-33.def.
> > (ucs)                Type H to see if it is available with options.
> > 
> > See the ucs package documentation for explanation.
> > Type  H <return>  for immediate help.
> >  ...
> > 
> > l.15507 \verb~"\U+2148"~ & A + Bⅈ
> >                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> > *********************************************************************
> > Please give me a hint to overcome this.
> > 
> > Tatsuro
> > 
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!ntDJkCbntUyvtjWACoyKxH33sOtgd2BWTy1sKBUr_PfkMeekvnd8fMKcYnq4T9tDitajZAx-6eNDbB7hfSIBopb4f9YyZA$ 
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!ntDJkCbntUyvtjWACoyKxH33sOtgd2BWTy1sKBUr_PfkMeekvnd8fMKcYnq4T9tDitajZAx-6eNDbB7hfSIBopb4f9YyZA$ 
> 


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

Re: Latex error on recent dev branch

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

I have met the following LaTeX error on the recent dev branch during make pdf.
> *********************************************************************
> ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> (ucs)                possibly declared in uni-33.def.
> (ucs)                Type H to see if it is available with options.
> 
> See the ucs package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...
> 
> l.15507 \verb~"\U+2148"~ & A + Bⅈ
>                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> *********************************************************************
> Please give me a hint to overcome this.

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "beta" <gnu...@li...>
> Date: 2025/07/18 金 09:10
> Subject: Latex error on recent dev branch
> 
> 
> I have met the following LaTeX error on the recent dev branch. 
> *********************************************************************
> ! Package ucs Error: Unknown Unicode character 8520 = U+2148,
> (ucs)                possibly declared in uni-33.def.
> (ucs)                Type H to see if it is available with options.
> 
> See the ucs package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...
> 
> l.15507 \verb~"\U+2148"~ & A + Bⅈ
>                                     & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
> *********************************************************************
> Please give me a hint to overcome this.
> 
> Tatsuro
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Latex error on recent dev branch

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

I have met the following LaTeX error on the recent dev branch. 
*********************************************************************
! Package ucs Error: Unknown Unicode character 8520 = U+2148,
(ucs)                possibly declared in uni-33.def.
(ucs)                Type H to see if it is available with options.

See the ucs package documentation for explanation.
Type  H <return>  for immediate help.
 ...

l.15507 \verb~"\U+2148"~ & A + Bⅈ
                                    & Unicode DOUBLE-STRUCK ITALIC SMALL I \\
*********************************************************************
Please give me a hint to overcome this.

Tatsuro