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

Re: problem installing gnuplot

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

On Thursday, 9 January 2025 13:38:22 PST Ozan Kahramanogullari wrote:
> Hi,
> 
> I am trying to install gnuplot following the instructions in the INSTALL
> file.
> 
> I could run  "./prepare" and "./configure" without problems but "make"
> failed with the error  message below.
> 
> I tried to debug the code, but it exceeded my capacity to do a quick fix. I
> also checked online, but I could not find a solution.
> 
> Can anyone help?
>
> I am using an M1 Mac, in case it is relevant.

Yes, very relevant.

First off, you can just ignore the warning that advises to use posix_spawn()
instead of fork().   The real problem is "undeclared function 'rl_getc'".

Gnuplot supports 3 alternative methods for terminal input.
The choice is made at build-time as part of the ./configure step.
1) The gnu readline library, selected by
    ./configure --with-readline=gnu
2) The BSD editline library, selected by
    ./configure --with-readline=bsd
3) A minimal but functional input layer that can be selected by
    ./configure --with-readline=builtin

If you do not specify any of these options, the configure script will pick
one for you based on what it thinks it knows about the library support
on your system.  I.e. first it will look for libreadline. If it doesn't find that
it looks for libeditline.  If it finds neither it will use the builtin code.

The problem is that MacOS provides a version of the BSD library with
a wrapper that makes it look like, or almost like, gnu readline.
I say "almost" because it does not provide 100% of the routines that
are present in gnu readline.  I think what is happening in your case is
that the configure script thinks it has found the readline library on your
system so it selects all the readline-appropriate calling options.
But what it really found was the imitation readline wrapper for libeditline.
That is normal for a Mac if you have not separately installed the "real"
readline library, and up until recently that was good enough for gnuplot.

Recently gnuplot's input layer was modified to use an undocumented
feature of the editline wrapper so that it would be possible to support
UTF-8 encoded terminal input. This worked great on the machines I was
able to test, but an M1 Mac was not among those machines.  I am guessing
that the wrapper provided on your machine does not provide a wrapper
for rl_getc(),  or just as likely it does have such a routine but fails to list it
in the "readline.h" header file that comes with the wrapper.

Here is the relevant chunk of code from gnuplot's file .../src/term.c:

> #if defined(HAVE_LIBREADLINE)
> 
>   #define raw() rl_prep_terminal(1)
>   #define cook() rl_deprep_terminal()
>   #define nextchar() rl_getc(stdin)
> 
> #elif defined(HAVE_LIBEDITLINE)
> 
>   #define raw() rl_prep_terminal(1)
>   #define cook() rl_deprep_terminal()
>   #define nextchar() fgetc(stdin)
> 
> #elif defined(READLINE)
> 
>   #define raw() set_termio()
>   #define cook() reset_termio()
>   #define nextchar() fgetc(stdin)
> 
> #endif

So, what can you do?

- It is possible that specifying one of the three input options  explicitly to ./configure
rather than letting it default would make it work. 
Certainly the builtin option should work.

- I am guessing that editing chunk of code shown above so that all three options say
     #define nextchar() fgetc(stdin)
would be the correct solution for a system with editline-masquerading-as-readline.
If you try that and it works, please let us know and we can try to teach the configure
script how to handle that.  Do you know if there is a compile-time symbol defined
on your machine to indicate that it is an M1?  That might be what we would have to
look for.

- I am also guessing that the "real" fix is to file a bug report against the readline.h
header provided by Apple.  But I'm not holding my breath on that one.
As I said, this is an undocumented option, and there may in fact be a reason for that.

	Ethan
 
> Best,
> Ozan
> 
> =======================
>  Ozan Kahramanoğulları, PhD
>               ozan-k.com
> =======================
> 
> (base) ozan@MBP-FVFGT17VQ05N gnuplot-gnuplot-main % make
> 
> /Library/Developer/CommandLineTools/usr/bin/make  all-recursive
> 
> Making all in config
> 
> make[2]: Nothing to be done for `all'.
> 
> Making all in m4
> 
> make[2]: Nothing to be done for `all'.
> 
> Making all in term
> 
> make[2]: Nothing to be done for `all'.
> 
> Making all in src
> 
> Making timestamp.h
> 
> /Library/Developer/CommandLineTools/usr/bin/make  all-recursive
> 
> Making all in wxterminal
> 
> make[4]: Nothing to be done for `all'.
> 
> Making all in qtterminal
> 
> make[4]: Nothing to be done for `all'.
> 
> depbase=`echo term.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> 
> gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
> -DBINDIR=\"/usr/local/bin\"
> -DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"
> -DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"
> -DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/6.1\"
> -DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/6.1/PostScript\"
> -DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/6.1/js\"
> -DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/6.1/lua\" -DCONTACT=\"
> gnu...@li...\"
> -DHELPFILE=\"/usr/local/share/gnuplot/6.1/gnuplot.gih\"
> -DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
> -DGNUPLOT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"  -DGNUPLOT_QT=\"`echo
> gnuplot_qt | sed 's,x,x,'`\"
> -DQTGNUPLOT_DATA_DIR=\"/usr/local/share/gnuplot/6.1/qt\" -I/usr/X11/include
> -g -O2 -MT term.o -MD -MP -MF $depbase.Tpo -c -o term.o term.c &&\
> 
> mv -f $depbase.Tpo $depbase.Po
> 
> In file included from term.c:1214:
> 
> In file included from ./term.h:187:
> 
> *../term/x11.trm:1084:6: **warning: **'fork' is deprecated: Use posix_spawn
> or fork [-Wdeprecated-declarations]*
> 
>  1084 |         if (fork() == 0) {
> 
>       | *            ^*
> 
> */Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1:
> note: *'fork' has been explicitly marked deprecated here
> 
>   604 | __deprecated_msg("Use posix_spawn or fork")
> 
>       | *^*
> 
> */Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48:
> note: *expanded from macro '__deprecated_msg'
> 
>   218 |         #define __deprecated_msg(_msg)
> __attribute__((__deprecated__(_msg)))
> 
>       | *                                                      ^*
> 
> *term.c:1382:13: **error: **call to undeclared function 'rl_getc'; ISO C99
> and later do not support implicit function declarations
> [-Wimplicit-function-declaration]*
> 
>  1382 |         nextchar = nextchar();
> 
>       | *                   ^*
> 
> *term.c:1360:22: note: *expanded from macro 'nextchar'
> 
>  1360 |   #define nextchar() rl_getc(stdin)
> 
>       | *                     ^*
> 
> 1 warning and 1 error generated.
> 
> make[4]: *** [term.o] Error 1
> 
> make[3]: *** [all-recursive] Error 1
> 
> make[2]: *** [all] Error 2
> 
> make[1]: *** [all-recursive] Error 1
> 
> make: *** [all] Error 2
> 


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

problem installing gnuplot

[Ozan K. <oza...@gm...>]

Hi,

I am trying to install gnuplot following the instructions in the INSTALL
file.

I could run  "./prepare" and "./configure" without problems but "make"
failed with the error  message below.

I tried to debug the code, but it exceeded my capacity to do a quick fix. I
also checked online, but I could not find a solution.

Can anyone help?

I am using an M1 Mac, in case it is relevant.

Best,
Ozan

=======================
 Ozan Kahramanoğulları, PhD
              ozan-k.com
=======================

(base) ozan@MBP-FVFGT17VQ05N gnuplot-gnuplot-main % make

/Library/Developer/CommandLineTools/usr/bin/make  all-recursive

Making all in config

make[2]: Nothing to be done for `all'.

Making all in m4

make[2]: Nothing to be done for `all'.

Making all in term

make[2]: Nothing to be done for `all'.

Making all in src

Making timestamp.h

/Library/Developer/CommandLineTools/usr/bin/make  all-recursive

Making all in wxterminal

make[4]: Nothing to be done for `all'.

Making all in qtterminal

make[4]: Nothing to be done for `all'.

depbase=`echo term.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\

gcc -DHAVE_CONFIG_H -I. -I..  -I../term -I../term
-DBINDIR=\"/usr/local/bin\"
-DX11_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"
-DQT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"
-DGNUPLOT_SHARE_DIR=\"/usr/local/share/gnuplot/6.1\"
-DGNUPLOT_PS_DIR=\"/usr/local/share/gnuplot/6.1/PostScript\"
-DGNUPLOT_JS_DIR=\"/usr/local/share/gnuplot/6.1/js\"
-DGNUPLOT_LUA_DIR=\"/usr/local/share/gnuplot/6.1/lua\" -DCONTACT=\"
gnu...@li...\"
-DHELPFILE=\"/usr/local/share/gnuplot/6.1/gnuplot.gih\"
-DGNUPLOT_X11=\"`echo gnuplot_x11 | sed 's,x,x,'`\"
-DGNUPLOT_DRIVER_DIR=\"/usr/local/libexec/gnuplot/6.1\"  -DGNUPLOT_QT=\"`echo
gnuplot_qt | sed 's,x,x,'`\"
-DQTGNUPLOT_DATA_DIR=\"/usr/local/share/gnuplot/6.1/qt\" -I/usr/X11/include
-g -O2 -MT term.o -MD -MP -MF $depbase.Tpo -c -o term.o term.c &&\

mv -f $depbase.Tpo $depbase.Po

In file included from term.c:1214:

In file included from ./term.h:187:

*../term/x11.trm:1084:6: **warning: **'fork' is deprecated: Use posix_spawn
or fork [-Wdeprecated-declarations]*

 1084 |         if (fork() == 0) {

      | *            ^*

*/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/unistd.h:604:1:
note: *'fork' has been explicitly marked deprecated here

  604 | __deprecated_msg("Use posix_spawn or fork")

      | *^*

*/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:218:48:
note: *expanded from macro '__deprecated_msg'

  218 |         #define __deprecated_msg(_msg)
__attribute__((__deprecated__(_msg)))

      | *                                                      ^*

*term.c:1382:13: **error: **call to undeclared function 'rl_getc'; ISO C99
and later do not support implicit function declarations
[-Wimplicit-function-declaration]*

 1382 |         nextchar = nextchar();

      | *                   ^*

*term.c:1360:22: note: *expanded from macro 'nextchar'

 1360 |   #define nextchar() rl_getc(stdin)

      | *                     ^*

1 warning and 1 error generated.

make[4]: *** [term.o] Error 1

make[3]: *** [all-recursive] Error 1

make[2]: *** [all] Error 2

make[1]: *** [all-recursive] Error 1

make: *** [all] Error 2

Re: Release 6.0.2

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

I have uploaded windows binary packages for 6.0.2.

Tatsuro

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "gnuplot beta list" <gnu...@li...>
> Date: 2024/12/21 土 14:37
> Subject: Release 6.0.2
> 
> 
> 
> A release tarball for version 6.0.2 is now available on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/6.0.2/gnuplot-6.0.2.tar.gz
> 
> Release Notes here:
>    Gnuplot 6.0.2
> 
> The release version differs from the testing version by one bug fix and a warning in the Release Notes about difficulties in rebuilding the documentation using pdflatex from TeXLive2024 (use luatex instead).
> 
> In addition to the usual minor bug fixes, 6.0.2 contains several new features from the development version of gnuplot that didn't quite make it into the initial version 6 release. See the release notes for more detail.
> 
> Notably, gnuplot 6.0.2 now handles UTF-8 characters in terminal input when linked against the BSD editline library. UTF-8 input has always worked with configuration options readline=gnu or readline=builtin; now it also works for
>    ./configure --with-readline=bsd
> 
> happy gnuplotting
>   Ethan
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Release 6.0.2

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

A release tarball for version 6.0.2 is now available on SourceForge

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

Release Notes here:
    Gnuplot 6.0.2 <https://gnuplot.sourceforge.net/ReleaseNotes_6_0_2.html>

The release version differs from the testing version by one bug fix and a
warning in the Release Notes about difficulties in rebuilding the
documentation using pdflatex from TeXLive2024 (use luatex instead).

In addition to the usual minor bug fixes, 6.0.2 contains several new
features from the development version of gnuplot that didn't quite make it
into the initial version 6 release.  See the release notes for more detail.

Notably, gnuplot 6.0.2 now handles UTF-8 characters in terminal input when
linked against the BSD editline library.  UTF-8 input has always worked
with configuration options readline=gnu or readline=builtin; now it also
works for
      ./configure --with-readline=bsd

happy gnuplotting
    Ethan

Re: Testing version of gnuplot 6.0.2

[Jun. T <tak...@kb...>]

Although I can build gnuplot.pdf either by TeXLive2023/pdflatex or
by TeXLive2024/lualatex, both method give the pdf with minor problems:
at around page 79 (or 78 or 80?), in the description of the Ellipses
style, the text does not wrap the figure correctly. It seems "picins"
is not working well (there may be a few more figures that have
similar problems). Does this happens only for me?

I also tried "make tikz" in docs/ directory (hoping it may give better
pdf), but the build failed at the target tikz_figures, with the following
error:
---------------
"./plotstyles.gnu" line 1142: /usr/local/share/gnuplot/6.1/lua/gnuplot-tikz.lua:395: attempt to concatenate a nil value (local 'color')
stack tracebac

line 0: Missing Lua context! No script?
(this message repeats endlessly)
---------------
The error occurs at the "splot" in the "Fence plot" in plotstyles.gnu,
but I don't know how to fix it.

Re: Testing version of gnuplot 6.0.2

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

On Monday, 9 December 2024 00:13:35 PST Henri Menke via gnuplot-beta wrote:
> > 
> > With the newest TeXLive (20240312 on Cygwin) gnuplot documentation
> > can no
> > longer be created since
> > 
> >     \usepackage{ucs}
> >     \usepackage[utf8x]{inputenc}
> > 
> > produces errors in internal TeX packages down the line.  I have not
> > found an invocation that circumvents this problem yet…
> 
> Could you please try simply replacing these two lines by
> 
>     \usepackage[utf8]{inputenc}
> 
> The ucs package (which is what provides the utf8x definition file) is
> basically unmaintained. Also since 2018 UTF-8 is the default encoding
> in LaTeX, so none of these packages should be necessary anymore.
> 
> Cheers, Henri

Is there a replacement for the ucs option \SetUnicodeOption{mathletters} ?
Without it the pdflatex build fails with message

    Error: Unicode character ∞ (U+221E) not set up for use with LaTeX

and equivalent messages for bullet (U+2219), square (U+25A1), en dash (U+2212) etc.
I tried adding additional commands

    \DeclareUnicodeCharacter{2212}{\ensuremath{\textendash}}
    ... and so on for each character it complained about ...

That allowed pdflatex to proceed further, but it still failed in the end
with fatal errors complaining about missing font maps for font grxn1000 and

    Warning: command \textendash invalid in math mode

So I have not yet managed to rebuild the gnuplot manual using
pdflatex or plain latex under TeXLive2024.

I'm happy enough using luatex instead;  we're already doing that for the
Japanese documentation.  And the distribution does include a pre-built copy
of gnuplot.pdf so most users would not need to rebuild it anyhow.

    Ethan

Re: Testing version of gnuplot 6.0.2

[Henri M. <he...@he...>]

On Sat, 2024-12-07 at 16:26 +0100, ASSI wrote:
> Ethan A Merritt writes:
> > I have placed a test package for release 6.0.2 in the "testing"
> > folder on SourceForge
> >     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> > 
> > The bug tracker has been pretty quiet lately so I hope most of the
> > issues in the 6.0
> > releases have been reported and now are fixed in 6.0.2.
> > 
> > Please report any build problems or other issues you find with the
> > test package.
> > If no problems arise I plan to use the same source files for a
> > release announcement
> > in a couple of weeks.
> 
> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation
> can no
> longer be created since
> 
>     \usepackage{ucs}
>     \usepackage[utf8x]{inputenc}
> 
> produces errors in internal TeX packages down the line.  I have not
> found an invocation that circumvents this problem yet…

Could you please try simply replacing these two lines by

    \usepackage[utf8]{inputenc}

The ucs package (which is what provides the utf8x definition file) is
basically unmaintained. Also since 2018 UTF-8 is the default encoding
in LaTeX, so none of these packages should be necessary anymore.

Cheers, Henri

> 
> 
> Regards,
> Achim.

Re: Testing version of gnuplot 6.0.2

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

ASSI writes:
>> Simplest work-around is to replace
>> 	PDFLATEX = pdflatex
>> with
>> 	PDFLATEX=luatex
>> in the .../docs/Makefile
>>
>> or do the same in the environment as part of the configuration process.
>
> OK, that should work, I'll report how that turns out.

OK, so that should be

 PDFLATEX=lualatex
 LATEX=dvilualatex

(I think), but then I get stuck with this wierd error when trying to create the PS file:

--8<---------------cut here---------------start------------->8---
' LuaTeX output 2024.12.08:2105' -> gnuplot.ps
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerifBold.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerifBold.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: PK font [/usr/share/fonts/gnu-free/FreeSerif.ttf] not found; using cmr10
</usr/share/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk>
dvips: Checksum mismatch in font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
dvips: ! [scanpage] invalid char 185 from font [/usr/share/fonts/gnu-free/FreeSerif.ttf]
make: *** [Makefile:1140: gnuplot.ps] Error 1
--8<---------------cut here---------------end--------------->8---

and this one for the PDF:

--8<---------------cut here---------------start------------->8---
GNUPLOT_LIB=/mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.2/demo ../src/gnuplot.exe /mnt/share/cygpkgs/gnuplot/gnuplot.x86_64/src/gnuplot-6.0.2/docs/plotstyles.gnu
*** buffer overflow detected ***: terminated
make: *** [Makefile:1065: pdf_figures] Error 127
--8<---------------cut here---------------end--------------->8---

Additionally, the parallel build is somehow broken again and I need to
compile in serial mode.


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

Re: Testing version of gnuplot 6.0.2

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

Ethan A Merritt writes:
>> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
>> longer be created since
>> 
>>     \usepackage{ucs}
>>     \usepackage[utf8x]{inputenc}
>> 
>> produces errors in internal TeX packages down the line.  I have not
>> found an invocation that circumvents this problem yet…
>
> Yes, I found that also. I reported it upstream.
> I believe the error in is the utf8x module but I haven't been able to figure
> out what changed from TeXLive2023 (which does work).

There was a specific ugly workaround to make some things in utf8x work (
especially in conjunction with ucs) even though development of that
package has apparently ceased.

> Simplest work-around is to replace
> 	PDFLATEX = pdflatex
> with
> 	PDFLATEX=luatex
> in the .../docs/Makefile
>
> or do the same in the environment as part of the configuration process.

OK, that should work, I'll report how that turns out.


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

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Testing version of gnuplot 6.0.2

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

On Saturday, 7 December 2024 07:26:48 PST ASSI wrote:

> Ethan A Merritt writes:
> > I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
> >
> > The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
> > releases have been reported and now are fixed in 6.0.2.
> >w
> > Please report any build problems or other issues you find with the test package.
> > If no problems arise I plan to use the same source files for a release announcement
> > in a couple of weeks.
> 
> With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
> longer be created since
> 
>     \usepackage{ucs}
>     \usepackage[utf8x]{inputenc}
> 
> produces errors in internal TeX packages down the line.  I have not
> found an invocation that circumvents this problem yet…

Yes, I found that also. I reported it upstream.
I believe the error in is the utf8x module but I haven't been able to figure
out what changed from TeXLive2023 (which does work).

Simplest work-around is to replace
	PDFLATEX = pdflatex
with
	PDFLATEX=luatex
in the .../docs/Makefile

or do the same in the environment as part of the configuration process.

bash$     PDFLATEX=luatex ./configure

  Ethan
> 
> Regards,
> Achim.
> 


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

Re: Testing version of gnuplot 6.0.2

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

Ethan A Merritt writes:
> I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
>     https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
> The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
> releases have been reported and now are fixed in 6.0.2.
>
> Please report any build problems or other issues you find with the test package.
> If no problems arise I plan to use the same source files for a release announcement
> in a couple of weeks.

With the newest TeXLive (20240312 on Cygwin) gnuplot documentation can no
longer be created since

    \usepackage{ucs}
    \usepackage[utf8x]{inputenc}

produces errors in internal TeX packages down the line.  I have not
found an invocation that circumvents this problem yet…


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

Testing version of gnuplot 6.0.2

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

I have placed a test package for release 6.0.2 in the "testing" folder on SourceForge
    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

The bug tracker has been pretty quiet lately so I hope most of the issues in the 6.0
releases have been reported and now are fixed in 6.0.2.

Please report any build problems or other issues you find with the test package.
If no problems arise I plan to use the same source files for a release announcement
in a couple of weeks.

Release notes appended below, or see

	gnuplot.sourceforge.net/ReleaseNotes_6_0_2.html

- Ethan


		Gnuplot Version 6.0.2 Release Notes
		===================================

This is the second incremental release for gnuplot stable version 6.0.
In addition to the usual minor bug fixes, it contains several new features
from the development version of gnuplot that didn't quite make it into
the initial version 6 release.

NEW (backported from development version)
-----------------------------------------
- plot style "with hsteps" enables a variety of new plot types
  For examples, see
	* https://gnuplot.info/demo_6.0/hsteps.html
	* https://gnuplot.info/demo_6.0/logic_timing.html
	* https://gnuplot.info/demo_6.0/rank_sequence.html

- 3D plot style "with filledcurves" provides additional flexibility in creating
  the family of plot styles that includes waterfall plots and fence plots.
  See
	* https://gnuplot.info/demo_6.0/waterfallplot.html

- Terminal input when gnuplot is linked against the BSD editline library
  now correctly handles UTF-8 characters.  UTF-8 input has always worked
  for configuration options readline=gnu or readline=builtin; now it also
  works for
      ./configure --with-readline=bsd

  This change should in particular benefit users of Debian and MacOS
  binaries, which are typically linked against the editline library.

- Polygons in a 3D plot ("splot ... with polygons") can use palette coloring
  and pm3d lighting.

- General binary keyword option "blank=NaN" facilitates using binary input
  data for plot styles that would require blank lines in a text input data
  stream. See
	* https://gnuplot.info/demo_6.0/binary_polygon.html

- "linestyle variable" is accepted as a color specifier in plot commands.
  The primary distinction between this as "linecolor variable" is that
  linestyle properties are cleared by the next "reset" command.
  This allows definition of a temporary color sequence affected only one plot.

CHANGES
-------
- Local variables are reimplemented to provide a better-defined scope
  and faster evaluation of function blocks.
- Existing plot styles steps, histeps, fsteps, and fillsteps are
  reimplemented to use the new hsteps code.
- Boxplot outlier position (horizontal displacement) is controlled by "set jitter".
- The content of $GPVAL_LAST_MULTIPLOT is appended to the output from "save"
  so that loading the saved file regenerates a full multiplot rather than
  only the final component.

FIXES
-----
- reworked generation of logscale axis tic marks                 (Bugs 2372 2717)
- Do not save extraneous commands to $GPVAL_LAST_MULTIPLOT       (Bug 2714)
- svg: modify gnuplot_svg.js to work in local standalone mode    (Bug 2715)
- wxt: release per-thread font data before entering "persist"    (Bug 2693)
- "set table": honor "nosurface" keyword in splot
- "set table": honor "set format z" when z is printed from plot
- better contouring near the edge of a z-clipped surface
- handle mousing of logscale axes in inactive plot windows       (Bug 2723)
- "set tics scale" does not change other axis tick properties    (Bug 2724)
- points with variable color value NaN should not be drawn       (Bug 2737)
- "set term tikz nostandalone" should suppress the latex wrapper (Bug 2740)
- handle unusual case of intersecting pm3d surfaces              (Bug 2744)

KNOWN ISSUES
------------
- Support for replot and pan/zoom mouse operations in multiplot mode
  is still incomplete. Expect further improvement in subsequent releases.
 

Re: possible overrun in wxt_gui.c

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

On Monday, 2 December 2024 03:43:01 PST Jun T wrote:
> When compiling wxt_gui.cpp, clang (on my Mac) gives warnings,
> in function wxt_update_mousecoords_in_window(), that strongly
> recommend using nsprintf() instead of sprintf().

Applied. Thanks

> 
> While trying to silence this warning, I've found that there
> is a possibility of overrun.
> 
> The format "%10g" (equivalent to "%10.6g") may use up to 13
> characters: "-1.23456e+123". So the buffer mouse_format[]
> may be overrun by the last sprintf(m, "y2=...",...).
> 
> In the patch below I removed some extra spaces in the format
> so that the string would look like (but not exactly the same
> as) the one in the status bar of the active window.
> 
> The condition 'left > 0' is added just in case "%10g" occupies
> more than 13 characters (I guess this should never happen).
> 
> 
> diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
> index 2cd096f01..d5249df58 100644
> --- a/src/wxterminal/wxt_gui.cpp
> +++ b/src/wxterminal/wxt_gui.cpp
> @@ -129,6 +129,9 @@ extern "C" {
>  #ifdef HAVE_SYS_SELECT_H
>  # include <sys/select.h>
>  #endif
> +#ifdef HAVE_WORKING_FORK
> +# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
> +#endif
>  }
>  
>  /* Interactive toggle control variables
> @@ -3272,29 +3275,17 @@ static void wxt_update_mousecoords_in_window(int number, int mx, int my)
>  	if ((window = wxt_findwindowbyid(number))) {
>  
>  		/* TODO: rescale mx and my using stored per-plot scale info */
> -		char mouse_format[66];
> +		char mouse_format[67]; // %10g may use at most 13 chars
>  		char *m = mouse_format;
> -		double x, y, x2, y2;
> -
> -		if (window->axis_mask & (1<<0)) {
> -			x = mouse_to_axis(mx, &window->axis_state[0]);
> -			sprintf(m, "x=  %10g   %c", x, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<1)) {
> -			y = mouse_to_axis(my, &window->axis_state[1]);
> -			sprintf(m, "y=  %10g   %c", y, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<2)) {
> -			x2 = mouse_to_axis(mx, &window->axis_state[2]);
> -			sprintf(m, "x2=  %10g   %c", x2, '\0');
> -			m += 17;
> -		}
> -		if (window->axis_mask & (1<<3)) {
> -			y2 = mouse_to_axis(my, &window->axis_state[3]);
> -			sprintf(m, "y2=  %10g %c", y2, '\0');
> -			m += 15;
> +		int left = sizeof(mouse_format);
> +		const char *name[4] = { "x", "y", "x2", "y2" };
> +		for (int i=0; i<4 && left > 0; ++i) {
> +			if (window->axis_mask & (1<<i)) {
> +				int n = snprintf(m, left, "%s=% -10g ", name[i],
> +							mouse_to_axis(mx, &window->axis_state[i]));
> +				m += n;
> +				left -= n;	// left<=0 if truncated (should not happen)
> +			}
>  		}
>  
>  		FPRINTF((stderr,"wxt : update mouse coords in window %d\n",number));

possible overrun in wxt_gui.c

[Jun T <tak...@kb...>]

When compiling wxt_gui.cpp, clang (on my Mac) gives warnings,
in function wxt_update_mousecoords_in_window(), that strongly
recommend using nsprintf() instead of sprintf().

While trying to silence this warning, I've found that there
is a possibility of overrun.

The format "%10g" (equivalent to "%10.6g") may use up to 13
characters: "-1.23456e+123". So the buffer mouse_format[]
may be overrun by the last sprintf(m, "y2=...",...).

In the patch below I removed some extra spaces in the format
so that the string would look like (but not exactly the same
as) the one in the status bar of the active window.

The condition 'left > 0' is added just in case "%10g" occupies
more than 13 characters (I guess this should never happen).


diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
index 2cd096f01..d5249df58 100644
--- a/src/wxterminal/wxt_gui.cpp
+++ b/src/wxterminal/wxt_gui.cpp
@@ -129,6 +129,9 @@ extern "C" {
 #ifdef HAVE_SYS_SELECT_H
 # include <sys/select.h>
 #endif
+#ifdef HAVE_WORKING_FORK
+# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
+#endif
 }
 
 /* Interactive toggle control variables
@@ -3272,29 +3275,17 @@ static void wxt_update_mousecoords_in_window(int number, int mx, int my)
 	if ((window = wxt_findwindowbyid(number))) {
 
 		/* TODO: rescale mx and my using stored per-plot scale info */
-		char mouse_format[66];
+		char mouse_format[67]; // %10g may use at most 13 chars
 		char *m = mouse_format;
-		double x, y, x2, y2;
-
-		if (window->axis_mask & (1<<0)) {
-			x = mouse_to_axis(mx, &window->axis_state[0]);
-			sprintf(m, "x=  %10g   %c", x, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<1)) {
-			y = mouse_to_axis(my, &window->axis_state[1]);
-			sprintf(m, "y=  %10g   %c", y, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<2)) {
-			x2 = mouse_to_axis(mx, &window->axis_state[2]);
-			sprintf(m, "x2=  %10g   %c", x2, '\0');
-			m += 17;
-		}
-		if (window->axis_mask & (1<<3)) {
-			y2 = mouse_to_axis(my, &window->axis_state[3]);
-			sprintf(m, "y2=  %10g %c", y2, '\0');
-			m += 15;
+		int left = sizeof(mouse_format);
+		const char *name[4] = { "x", "y", "x2", "y2" };
+		for (int i=0; i<4 && left > 0; ++i) {
+			if (window->axis_mask & (1<<i)) {
+				int n = snprintf(m, left, "%s=% -10g ", name[i],
+							mouse_to_axis(mx, &window->axis_state[i]));
+				m += n;
+				left -= n;	// left<=0 if truncated (should not happen)
+			}
 		}
 
 		FPRINTF((stderr,"wxt : update mouse coords in window %d\n",number));

Re: build fails: pango_cairo_font_map_set_default() not declared

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

On Sunday, 1 December 2024 20:39:05 PST Jun T wrote:

Applied. Thanks.

> After the commit:
> 
> commit 35643d86af5f41011723c7363172628283c0b96d
>     wxt: release per-thread font data structures before forking
> 
> build fails on my Mac (with clang) as:
> wxterminal/wxt_gui.cpp:3868:3: error: use of undeclared identifier 'pango_cairo_font_map_set_default'
> 
> We need to include <pango/pangocairo.h> either in wxt_gui.cpp (as in
> the patch below) or in wxt_gui.h (whichever you prefer).
> 
> 
> diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
> index 2cd096f01..35528e2cb 100644
> --- a/src/wxterminal/wxt_gui.cpp
> +++ b/src/wxterminal/wxt_gui.cpp
> @@ -129,6 +129,9 @@ extern "C" {
>  #ifdef HAVE_SYS_SELECT_H
>  # include <sys/select.h>
>  #endif
> +#ifdef HAVE_WORKING_FORK
> +# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
> +#endif
>  }
>  
>  /* Interactive toggle control variables
> 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!mxrckcjoWwlBc2lLsGWcarM6eKyjY6vbi-He9_m62jldT9Pg9v11CzSDtz6mjPaFe22f7UtYjVkhwYoF3CX69bAJJWo$ 
> 


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

build fails: pango_cairo_font_map_set_default() not declared

[Jun T <tak...@kb...>]

After the commit:

commit 35643d86af5f41011723c7363172628283c0b96d
    wxt: release per-thread font data structures before forking

build fails on my Mac (with clang) as:
wxterminal/wxt_gui.cpp:3868:3: error: use of undeclared identifier 'pango_cairo_font_map_set_default'

We need to include <pango/pangocairo.h> either in wxt_gui.cpp (as in
the patch below) or in wxt_gui.h (whichever you prefer).


diff --git a/src/wxterminal/wxt_gui.cpp b/src/wxterminal/wxt_gui.cpp
index 2cd096f01..35528e2cb 100644
--- a/src/wxterminal/wxt_gui.cpp
+++ b/src/wxterminal/wxt_gui.cpp
@@ -129,6 +129,9 @@ extern "C" {
 #ifdef HAVE_SYS_SELECT_H
 # include <sys/select.h>
 #endif
+#ifdef HAVE_WORKING_FORK
+# include <pango/pangocairo.h>	// for pango_cairo_font_map_set_default()
+#endif
 }
 
 /* Interactive toggle control variables

Re: update x-y ranges?

[Leo B. <leo...@um...>]

On Thu, Nov 28 2024, Hans-Bernhard Bröker <HBB...@t-...> wrote:

> Am 28.11.2024 um 21:05 schrieb Leo Butler:
>
>> w filledcurves~a xy=~a,~a lc ~a axis ~a
>> (the ~a are place holder for values, like %s in a printf template).
>> 1. Was this syntax ever supported by gnuplot? If so, what did it do
>> and
>>     how can the same effect be achieved in more recent gnuplots?
>
> I think that would depend on what the very first of those ~a thingies
> expands to.
>
> The documented syntax and the existing demos both suggest the 'xy='
> part to come rather immediately after "filledcurves".  The syntax only
> allows keywords like 'above' or 'below' in that place.  See "help with
> filledcurves" on current git head:
>
>> Syntax for 2D:
>>      plot f(x) with filledcurves [option]
>>      plot DATA using 1:2    with filledcurves [option]
>>      plot DATA using 1:2:3  with filledcurves [option]
>>  where the option can be one of the following
>>      closed
>>      {above|below} x1 x2  y r=<a> xy=<x>,<y>
>>      between

Ahhh, thank you. I did not understand that the 'xy=' clause was an
option for 'filledcurves'.

After looking at the git log more carefully, the error was introduced a
couple years. I have done as you suggested and corrected the error.

Thanks, Hans-Bernhard and Evan, for your help.

Best regards,
Leo

Re: update x-y ranges?

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

On Thursday, 28 November 2024 12:05:39 PST Leo Butler wrote:
> Hi,
> 
> I am not sure if this is the right venue, please re-direct me if it is not.
> 
> In the Maxima package draw [1], one finds a snippet of gnuplot code that
> goes like this:
> 
> w filledcurves~a xy=~a,~a lc ~a axis ~a
> 
> (the ~a are place holder for values, like %s in a printf template).
> 
> According to git, this line was checked in on the first commit of the
> package 18 years ago. We got a bug report yesterday [2] that the part
> 
> xy=....
> 
> is causing an error.
> 
> I have attached the Gnuplot file generated by a trimmed down example
> extracted from that bug report.
> 
> My questions are:
> 
> 1. Was this syntax ever supported by gnuplot? If so, what did it do and
>    how can the same effect be achieved in more recent gnuplots?

It is still supported.  See "help filledcurves".

The error is that this option must immediately follow the "with filledcurves".
Your script sticks an unrelated option (fillstyle solid 0.1) in between the
plot style and the plotstyle-specific options.

After swapping the position of "fillstyle solid 0.1" and "xy=-1.0,0.0" in the
plot command, the script runs without error in both gnuplot 5 and gnuplot 6.

Eighteen years ago  would have been early gnuplot version 4, I think, and 
many of the options in your script did not exist, including "fillstyle solid 0.1".

	Ethan

> 2. Assuming the syntax was supported, when was support removed?
> TIA,
> Leo
> 
> 
> [1] - https://urldefense.com/v3/__https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp*l902__;Iw!!K-Hz7m0Vt54!lkzvVp1SpWsUImWc4fB3wG8IS2eDAXgREdoZNLaZ-T2LJ0Qf3VWTarY4SQx8aNSFweyKiYY_3BJzMmM2ggZ5KTkdl_MsIA$ 
> 
> [2] - https://urldefense.com/v3/__https://sourceforge.net/p/maxima/bugs/4424/__;!!K-Hz7m0Vt54!lkzvVp1SpWsUImWc4fB3wG8IS2eDAXgREdoZNLaZ-T2LJ0Qf3VWTarY4SQx8aNSFweyKiYY_3BJzMmM2ggZ5KTnC6B_VdA$ 
> 
> 


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

Re: update x-y ranges?

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

Am 28.11.2024 um 21:05 schrieb Leo Butler:

> w filledcurves~a xy=~a,~a lc ~a axis ~a
> 
> (the ~a are place holder for values, like %s in a printf template).
> 
> 
> 1. Was this syntax ever supported by gnuplot? If so, what did it do and
>     how can the same effect be achieved in more recent gnuplots?

I think that would depend on what the very first of those ~a thingies 
expands to.

The documented syntax and the existing demos both suggest the 'xy=' part 
to come rather immediately after "filledcurves".  The syntax only allows 
keywords like 'above' or 'below' in that place.  See "help with 
filledcurves" on current git head:

> Syntax for 2D:
> 
>      plot f(x) with filledcurves [option]
>      plot DATA using 1:2    with filledcurves [option]
>      plot DATA using 1:2:3  with filledcurves [option]
> 
>  where the option can be one of the following
> 
>      closed
>      {above|below} x1 x2  y r=<a> xy=<x>,<y>
>      between

That would indicate this fraction of the command line rejected by 
gnuplot (from [1])

	w filledcurves fillstyle solid 0.1 xy=-1.0,0.0

would probably still work if it hat been

	w filledcurves xy=-1.0,0.0 fillstyle solid 0.1

instead.

> 2. Assuming the syntax was supported, when was support removed?

That particular syntax was never explicitly supported.  It may just have 
happened to work anyway.  And now it doesn't.

> [1] - https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp#l902

update x-y ranges?

[Leo B. <leo...@um...>]

Hi,

I am not sure if this is the right venue, please re-direct me if it is
not.

In the Maxima package draw [1], one finds a snippet of gnuplot code that
goes like this:

w filledcurves~a xy=~a,~a lc ~a axis ~a

(the ~a are place holder for values, like %s in a printf template).

According to git, this line was checked in on the first commit of the
package 18 years ago. We got a bug report yesterday [2] that the part

xy=....

is causing an error.

I have attached the Gnuplot file generated by a trimmed down example
extracted from that bug report.

My questions are:

1. Was this syntax ever supported by gnuplot? If so, what did it do and
   how can the same effect be achieved in more recent gnuplots?
2. Assuming the syntax was supported, when was support removed?

TIA,
Leo


[1] - https://sourceforge.net/p/maxima/code/ci/master/tree/share/draw/gnuplot.lisp#l902

[2] - https://sourceforge.net/p/maxima/bugs/4424/

Re: format of win/README-Windows-jp.txt

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

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2024/08/08 木 04:34
> Subject: Re: format of win/README-Windows-jp.txt
> 
> 
> On Sunday, 4 August 2024 17:05:32 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > 
> > README-Windows-ja.txt is for users to read and for the binary distribution.
> > README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
> > Only README-Windows-ja.txt is needed and README.win-ja is not necessary.
> > 
> > 
> > > All three files have been converted to UTF-8 in the development branch.
> > > Should they be reverted to Shift-JIS?
> > 
> > It is better to be reverted. Sorry for my previous incorrect writing.
> > 
> > Tatsuro
> 
> I have converted  README-Windows-ja.txt from UTF-8 back to Shift-JIS
> in branch-6-0-stable.
> 
> Please check that this worked correctly, since I cannot read Shift-JIS files here.
> 
> thanks,
> 
> 	Ethan
> 
Ethan

Thanks for your treatment.
I  have confirmed that it will fix the glitch.

Tatsuro

Re: format of win/README-Windows-jp.txt

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

On Sunday, 4 August 2024 17:05:32 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> 
> README-Windows-ja.txt is for users to read and for the binary distribution.
> README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
> Only README-Windows-ja.txt is needed and README.win-ja is not necessary.
> 
> 
> > All three files have been converted to UTF-8 in the development branch.
> > Should they be reverted to Shift-JIS?
> 
> It is better to be reverted. Sorry for my previous incorrect writing.
> 
> Tatsuro

I have converted  README-Windows-ja.txt from UTF-8 back to Shift-JIS
in branch-6-0-stable.

Please check that this worked correctly, since I cannot read Shift-JIS files here.

thanks,

	Ethan

Re: Re: format of win/README-Windows-jp.txt

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

> ----- Original Message -----
> 
> From: "Ethan A Merritt" <me...@uw...>
> To: "beta" <gnu...@li...>
> Cc: "Tatsuro MATSUOKA" <tma...@ya...>
> Date: 2024/08/04 日 03:37
> Subject: Re: format of win/README-Windows-jp.txt
> 
> 
> On Thursday, 1 August 2024 22:01:46 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> > 
> > When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
> > The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
> > After converting the file to Shift_JIS, the characters are no longer garbled.
> > If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
> > it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.
> > 
> > Tatsuro
> 
> I received advice, perhaps incorrect, that the Japanese localization of
> Windows can now read UTF-8 files.
> Please help me to understand exactly when, and for which files,
> it is still necessary to provide Shift-JIS encoding.
> 
> As of December 2023 there were 3 files in the repository using Shift-JIS
>     ./win/README-Windows-ja.txt
>     ./src/win/README.win-ja
>     ./win/Copyright-ja.txt
> 
> I thought that the first file (README-Windows-ja.txt) was for users to read.
> I thought that the second file (README.win-ja) was for the binary distribution.
> Is this wrong?
> Are both README files needed?
> Do both of them need to be in Shift-JIS for the installer to work?
> 
> All three files have been converted to UTF-8 in the development branch.
> Should they be reverted to Shift-JIS?
> 
>     Ethan   
> 

> I thought that the first file (README-Windows-ja.txt) was for users to read.
> I thought that the second file (README.win-ja) was for the binary distribution.
> Is this wrong?
> Are both README files needed?

README-Windows-ja.txt is for users to read and for the binary distribution.
README.win-ja is for Japanese localization but it is outdated and is not included in binary distribution.
Only README-Windows-ja.txt is needed and README.win-ja is not necessary.


> All three files have been converted to UTF-8 in the development branch.
> Should they be reverted to Shift-JIS?

It is better to be reverted. Sorry for my previous incorrect writing.

Tatsuro

Re: format of win/README-Windows-jp.txt

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

On Thursday, 1 August 2024 22:01:46 PDT Tatsuro MATSUOKA via gnuplot-beta wrote:
> 
> When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
> The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
> After converting the file to Shift_JIS, the characters are no longer garbled.
> If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
> it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.
> 
> Tatsuro

I received advice, perhaps incorrect, that the Japanese localization of
Windows can now read UTF-8 files.
Please help me to understand exactly when, and for which files,
it is still necessary to provide Shift-JIS encoding.

As of December 2023 there were 3 files in the repository using Shift-JIS
    ./win/README-Windows-ja.txt
    ./src/win/README.win-ja
    ./win/Copyright-ja.txt

I thought that the first file (README-Windows-ja.txt) was for users to read.
I thought that the second file (README.win-ja) was for the binary distribution.
Is this wrong?
Are both README files needed?
Do both of them need to be in Shift-JIS for the installer to work?

All three files have been converted to UTF-8 in the development branch.
Should they be reverted to Shift-JIS?

    Ethan   


-- 
Ethan A Merritt

format of win/README-Windows-jp.txt

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

When upgrading from gnuplot-6.0.0 to gnuplot-6.0.1, win/README-Windows-ja.txt changed from Shift_JIS to UTF-8.
The win/README-Windows.txt file that appears at the beginning of the installer was garbled in Japanese environment.
After converting the file to Shift_JIS, the characters are no longer garbled.
If win/README-Windows-ja.txt is to be maintained in UTF-8 in the gnuplot repository, 
it may be necessary to include a process in the Makefile (config/mingw/Makefile) to convert the code to Shift_JIS when making the file.

Tatsuro