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

Re: gnuplot crashes if GNUPLOT_DRIVER_DIR is invalid

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

On Sunday, 11 June 2023 20:03:02 PDT Dima Kogan wrote:> 
> Reproducible like this:
> 
>   GNUPLOT_DRIVER_DIR='' ./gnuplot
> 
> It should report an error message, but not crash.
> 
> Fixed in the attached patch

Got it. Thanks.

Re: pdfcairo terminal; seams between bars in the colorbox

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

On Sunday, 11 June 2023 20:44:31 PDT Dima Kogan wrote:

> Sorry for yet another email. I was dogfooding the patch, and found a
> minor bug. Sometimes term->image is not available, and the new colorbox
> implementation crashes in that case. I added a check to the top of the
> function, and it's good now:
> 
>   static void
>   draw_inside_colorbox_bitmap_smooth()
>   {
>       if(term->image == NULL)
>           return;
>   .....
> 
> I hit this with the "dumb" terminal. I think not rendering the colorbox
> at all in that case is fine. Are there other terminals where term->image
> is unavailable, but drawing discrete slices would still have produced
> good output?

It will take a while for me to work my way through your proposed changes.
But this much I can answer quickly -
Yes there are terminals that support smooth palette color but not term->image().
At a minimum they include
 block
 cgm
 emf
 fig
 sixeltek

	Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

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

Sorry for yet another email. I was dogfooding the patch, and found a
minor bug. Sometimes term->image is not available, and the new colorbox
implementation crashes in that case. I added a check to the top of the
function, and it's good now:

  static void
  draw_inside_colorbox_bitmap_smooth()
  {
      if(term->image == NULL)
          return;
  .....

I hit this with the "dumb" terminal. I think not rendering the colorbox
at all in that case is fine. Are there other terminals where term->image
is unavailable, but drawing discrete slices would still have produced
good output?

gnuplot crashes if GNUPLOT_DRIVER_DIR is invalid

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

Reproducible like this:

  GNUPLOT_DRIVER_DIR='' ./gnuplot

It should report an error message, but not crash.

Fixed in the attached patch

Re: pdfcairo terminal; seams between bars in the colorbox

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

Oh, and two more notes, where the old code had off-by-one errors

- There old code was set up to overlap each colorbox by extending the
  bottom/right edge of each slice: GPMIN(xy_to,xy2+1)

  But that logic applies to all the slices, even the last one. This
  resulted in the last slice being one unit out-of-bounds

- The old code was computing the colors for each slice like this:

    for (i = 0; i < steps; i++)
      gray = i / (double)steps;

  This is another off-by-one error. The colors in the colorbox spanned
  [0,1-1/steps] instead of [0,1]. My patch fixes this one.

  There's some funky logic in quanize_gray() that maybe is trying to
  deal with this in the limited-max-colors case, but it's not commented,
  and applies to only this case. Code:

    qgray = floor(gray * sm_palette.use_maxcolors)
		        / (sm_palette.use_maxcolors-1);

  That should be made unnecessary

Re: pdfcairo terminal; seams between bars in the colorbox

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

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

> I may not understand what you are suggesting.

Hi. I guess I wasn't clear. The suggestion was that instead of creating
128 discrete bars with different colors we create a 128x1 bitmap and
draw it as an image. The thought was that this would work because images
look correct in pdfcairo, without the ugly border lines.

I implemented this in the attached patch, and it works and looks good. I
tried several gnuplot terminals (x11, qt, wxt, pdfcairo, png, svg), and
it looks like it works there too. I haven't found anything that this
breaks. The script I used to test:

  plot 'demo/blutux.rgb' binary array=(128,128) flipy format='%uchar' with rgbimage, 5 with points palette

I don't understand the gnuplot codebase deeply, so I might have missed
things. Some questions:

- I patched draw_inside_colorbox_bitmap_smooth() only. There are other
  flavors of this function (look where it is called), and I don't know
  if the others should be updated in this way as well

- I have an extra "gray = 1 - gray;" that I don't understand. It makes
  things correct, though

- The patch uses rgb unconditionally. I that going to break something in
  some terminal?

- I copied most of the logic from the old function without an
  understanding of what it does. Am I handling these properly?

    - sm_palette.use_maxcolors
    - sm_palette.gradient_num
    - sm_palette.positive

- If I "set colorbox horizontal" then the colorbox stays in the same
  spot with the same shape, but I change the color sequence to move
  horizontally. This happens even before my patch. I'm here:

    ae7dfa3f3..: Ethan A Merritt 2023-06-09 qt:  qt4 was apparently weak at int->double promotion

  Shouldn't the colorbox move below or above the plot, and reorient
  itself? Or is it the user's job to set the geometry?

This makes my PDFs look nice. It'd be good if some version of this patch
was merged.

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

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

On Sunday, 11 June 2023 14:14:27 PDT Dima Kogan wrote:
> 
> > I have never looked at the code for evince or mupdf. Okular and Evince
> > both claim to use the poppler library for rendering pdf files, so I am
> > a bit surprised thay behave differently. Is it possible that the
> > installations you tested were linked against different versions of
> > poppler?
> 
> I'm using the vanilla debian builds. Neither uses poppler today, for
> what it's worth.

https://wiki.gnome.org/Apps/Evince/PopplerBugs[1]
https://www.mail-archive.com/kde...@kd.../msg795457.html[2]

	Ethan



--------
[1] https://wiki.gnome.org/Apps/Evince/PopplerBugs
[2] https://www.mail-archive.com/kde...@kd.../msg795457.html

Re: pdfcairo terminal; seams between bars in the colorbox

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

On Sunday, 11 June 2023 14:14:27 PDT Dima Kogan wrote:
> >> What if we change the code from
> >>   calling term->filled_polygon() for each colorbox slice
> >> to
> >>   calling term->image() once for the whole colorbox
> >
> > In the case of pdf output it would mean going through the cairo
> > library either way. I wouldn't necessarily expect a difference.
> 
> I would expect it to fix things because gnuplot images look good with
> all pdf readers. Can you think of reasons such a patch wouldn't be a
> good idea? The fact that it wasn't done this way to begin with makes me
> think there's some reason.

I may not understand what you are suggesting.

Right now in order to create pdf output the code is calling 
cairotrm_filled_polygon() to render pixels into a cairo surface which
is eventually output as a pdf file.

I understood your suggestion to be that the program would instead
create a separate cairo png surface, use cairotrm_filled_polygon() to render
the pixels, then copy the pixels from the png surface to the pdf surface.

It is not obvious to me that the extra step would change the final output.
The same calls to cairotrm_filled_polygon() would be rendered
either way.  Copying the block of rendered pixels from one cairo surface to
another should not, I would think, change anything.

Anyhow, such a change would be specific to the cairo terminals.
We would not want to introduce a dependence on cairo image creation
when drawing the color box from other terminal types.

	Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

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

> I have never looked at the code for evince or mupdf. Okular and Evince
> both claim to use the poppler library for rendering pdf files, so I am
> a bit surprised thay behave differently. Is it possible that the
> installations you tested were linked against different versions of
> poppler?

I'm using the vanilla debian builds. Neither uses poppler today, for
what it's worth.


>> What if we change the code from
>>   calling term->filled_polygon() for each colorbox slice
>> to
>>   calling term->image() once for the whole colorbox
>
> In the case of pdf output it would mean going through the cairo
> library either way. I wouldn't necessarily expect a difference.

I would expect it to fix things because gnuplot images look good with
all pdf readers. Can you think of reasons such a patch wouldn't be a
good idea? The fact that it wasn't done this way to begin with makes me
think there's some reason.

Thanks

Re: pdfcairo terminal; seams between bars in the colorbox

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

On Saturday, 10 June 2023 17:04:49 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > It is likely that the artefact is due to the viewing program rather
> > than being intrinsic to the pdf file output by gnuplot.  I see no such
> > effect when viewing with the current version of okular
> 
> Interesting. I tried mupdf and evince prior to writing the email, and
> they both don't look right. I just tried okular, and like you say, it
> looks ok. And gv looks ok too.
> 
> I'd like it to look right in the others. Is this a BUG in the other
> viewers? I.e. is this something that a bug can be filed about?

Many years ago I identified the bug in gv and suggested a fix;
I do not know whether my suggestion was eventually adopted or some
other change was made.  That was years ago and I do not recall
the exact details. I have never looked at the code for evince or mupdf.

Okular and Evince both claim to use the poppler library for rendering
pdf files, so I am a bit surprised thay behave differently.
Is it possible that the installations you tested were linked against
different versions of poppler?

> What if we change the code from
>   calling term->filled_polygon() for each colorbox slice
> to
>   calling term->image() once for the whole colorbox

In the case of pdf output it would mean going through the cairo library
either way.  I wouldn't necessarily expect a difference. 

    Ethan

Re: pdfcairo terminal; seams between bars in the colorbox

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

Actually, okular doesn't fully work either.

I'm currently writing a presentation where I'm using pdflatex and I'm
including gnuplot figures. In that context okular shows the bands also.
Maybe pdflatex is also buggy, but if mupdf AND evince AND pdflatex have
this bug, maybe we should try to work around it. gv is still ok.

You can see this for yourself probably. I downloaded this figure that
was generated by gnuplot:

  http://mrcal.secretsauce.net/external/figures/diff/diff-radius0-heatmap-splined-opencv8.pdf

And ran "pdflatex tst.tex" where tst.tex is:

  \documentclass[presentation]{beamer}
  \begin{document}
  \includegraphics[keepaspectratio,width=0.9\textwidth,height=0.7\textheight]{/tmp/diff-radius0-heatmap-splined-opencv8.pdf}
  \end{document}

The result is attached. I see the bands even with okular.

Re: pdfcairo terminal; seams between bars in the colorbox

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

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

> It is likely that the artefact is due to the viewing program rather
> than being intrinsic to the pdf file output by gnuplot.  I see no such
> effect when viewing with the current version of okular

Interesting. I tried mupdf and evince prior to writing the email, and
they both don't look right. I just tried okular, and like you say, it
looks ok. And gv looks ok too.

I'd like it to look right in the others. Is this a BUG in the other
viewers? I.e. is this something that a bug can be filed about?

What if we change the code from

  calling term->filled_polygon() for each colorbox slice

to

  calling term->image() once for the whole colorbox

Would that break something?

Re: pdfcairo terminal; seams between bars in the colorbox

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

It is likely that the artefact is due to the viewing program rather
than being intrinsic to the pdf file output by gnuplot.  I see no such
effect when viewing with the current version of okular, although at
various times in the past I have found that toggling anti-alias in the
viewer settings can make a difference in some cases.  "gv" used to be
quite bad in this regard but has improved since then.

The quadrangles making up a pm3d surface can have the same, or
similar, problem.  That was mitigated by adding an option "set pm3d
border retrace", which can reduce or remove this artifact for solid
fill areas at the cost of introducing a "phantom grid" artifact for
semi-transparent fill areas.   I do not remember at the moment if a
similar treatment was added, or could be added, to the quadrangles
making up the color box.

On Sat, Jun 10, 2023 at 12:56 PM Dima Kogan
<gn...@di...> wrote:
>
> !-------------------------------------------------------------------|
>   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.
> |-------------------------------------------------------------------!
>
> Hi. I'm seeing ugly lines between the bars in the colorbox when making
> .pdf files. Trivial plot to demo this:
>
>   set terminal pdf
>   set output "/tmp/tst.pdf"
>   plot 5 with points palette
>
> This isn't a new issue, and I was wondering if anybody here had insight
> about fixing it.
>
> gp_cairo.c says this:
>
>   /* By default, Cairo uses an antialiasing algorithm which may
>    * leave a seam between polygons which share a common edge.
>    * Several solutions allow to workaround this behaviour :
>    * - don't antialias the polygons
>    *   Problem : aliased lines are ugly
>    * - stroke on each edge
>    *   Problem : stroking is a very time-consuming operation
>    * - draw without antialiasing to a separate context of a bigger size
>    *   Problem : not really in the spirit of the rest of the drawing.
>    * - enlarge the polygons so that they overlap slightly
>    *   Problem : It is really more time-consuming that it may seem.
>    *   It implies inspecting each corner to find which direction to move it
>    *   (making the difference between the inside and the outside of the polygon).
>    * - using CAIRO_OPERATOR_SATURATE
>    *   Problem : for each set of polygons, we have to draw front-to-back
>    *   on a separate context and then copy back to this one.
>    *   Time-consuming but probably less than stroking all the edges.
>    *
>    * The last solution is implemented if plot->polygons_saturate is set to TRUE
>    * Otherwise the default (antialiasing but may have seams) is used.
>    */
>
> And the gnuplot code today already does the "enlarge the polygons so
> that they overlap slightly" thing. color.c has:
>
>   draw_inside_colorbox_bitmap_smooth() {
>     ...
>     for (i = 0, xy2 = xy_from; i < steps; i++) {
>
>         xy = xy2;
>         xy2 = xy_from + (int) (xy_step * (i + 1));
>
>         ...
>         if (color_box.rotation == 'v') {
>             corners[0].y = corners[1].y = xy;
>             corners[2].y = corners[3].y = GPMIN(xy_to,xy2+1);
>         } else {
>             corners[0].x = corners[3].x = xy;
>             corners[1].x = corners[2].x = GPMIN(xy_to,xy2+1);
>         }
>     ...
>     }
>
> Note the "+1". I still see the ugly bars in the resulting .pdf file
> though. I can run experiments, but before I do anything, does anybody
> have a comment? The draw_inside_colorbox_bitmap_smooth() stuff changed
> in 2020, so maybe looking deeper at the effects of that patch would be
> an interesting thing to do.
>
> Thanks
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/gnuplot-beta__;!!K-Hz7m0Vt54!gvmIXc1ZjdPjHB_McnIXjBk792CcUxJIsyISfkYLL-khZyZZpKxIltBsw8-8FEqW9sKJr2ZQwh0CDRgiIi_iCkB-blo_0w$



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

pdfcairo terminal; seams between bars in the colorbox

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

Hi. I'm seeing ugly lines between the bars in the colorbox when making
.pdf files. Trivial plot to demo this:

  set terminal pdf
  set output "/tmp/tst.pdf"
  plot 5 with points palette

This isn't a new issue, and I was wondering if anybody here had insight
about fixing it.

gp_cairo.c says this:

  /* By default, Cairo uses an antialiasing algorithm which may
   * leave a seam between polygons which share a common edge.
   * Several solutions allow to workaround this behaviour :
   * - don't antialias the polygons
   *   Problem : aliased lines are ugly
   * - stroke on each edge
   *   Problem : stroking is a very time-consuming operation
   * - draw without antialiasing to a separate context of a bigger size
   *   Problem : not really in the spirit of the rest of the drawing.
   * - enlarge the polygons so that they overlap slightly
   *   Problem : It is really more time-consuming that it may seem.
   *   It implies inspecting each corner to find which direction to move it
   *   (making the difference between the inside and the outside of the polygon).
   * - using CAIRO_OPERATOR_SATURATE
   *   Problem : for each set of polygons, we have to draw front-to-back
   *   on a separate context and then copy back to this one.
   *   Time-consuming but probably less than stroking all the edges.
   *
   * The last solution is implemented if plot->polygons_saturate is set to TRUE
   * Otherwise the default (antialiasing but may have seams) is used.
   */

And the gnuplot code today already does the "enlarge the polygons so
that they overlap slightly" thing. color.c has:

  draw_inside_colorbox_bitmap_smooth() {
    ...
    for (i = 0, xy2 = xy_from; i < steps; i++) {

	xy = xy2;
	xy2 = xy_from + (int) (xy_step * (i + 1));

        ...
	if (color_box.rotation == 'v') {
	    corners[0].y = corners[1].y = xy;
	    corners[2].y = corners[3].y = GPMIN(xy_to,xy2+1);
	} else {
	    corners[0].x = corners[3].x = xy;
	    corners[1].x = corners[2].x = GPMIN(xy_to,xy2+1);
	}
    ...
    }

Note the "+1". I still see the ugly bars in the resulting .pdf file
though. I can run experiments, but before I do anything, does anybody
have a comment? The draw_inside_colorbox_bitmap_smooth() stuff changed
in 2020, so maybe looking deeper at the effects of that patch would be
an interesting thing to do.

Thanks

Re: Gnuplot 5.4.8 release

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

I have uploaded Windows binary packacges for 5.4.8.

Tatsuro

> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "beta" <gnu...@li...>
> Date: 2023/06/09 金 16:14
> Subject: Re: Re: Gnuplot 5.4.8 release
> 
> 
> Hello
> 
> I will prepare Windows binary packages for 5.4.8 tomorrow morning (JST).
> 
> Tatsuro
> 
> 
> > ----- Original Message -----
> > 
> > From: "Jun T" <tak...@kb...>
> > To: "Ethan A Merritt via gnuplot-beta" <gnu...@li...>
> > Date: 2023/06/09 金 12:34
> > Subject: Re: Gnuplot 5.4.8 release
> > 
> > 
> > 
> > > 2023/06/08 2:06, Ethan A Merritt <me...@uw...> wrote:
> > > 
> > > Gnuplot 5.4.8
> > 
> > As many of you already know, the gnuplot Web sites are
> > not updated recently:
> > 
> > Main gnuplot page:
> > http://www.gnuplot.info, under "Version 5.4 (current)"
> > it has a link to "Release 5.4.5 (October 2022)"
> > and also to the "Release Notes" of 5.4.5.
> > 
> > The download page: http://www.gnuplot.info/download.html
> > it says "The most recent release was 5.4.2 (June 2021)"
> > 
> > source forge:
> > https://sourceforge.net/projects/gnuplot/files/gnuplot/
> > the "Download Latest Version" button links to 5.4.7
> > 
> > 
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Re: Gnuplot 5.4.8 release

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

Hello

I will prepare Windows binary packages for 5.4.8 tomorrow morning (JST).

Tatsuro


> ----- Original Message -----
> 
> From: "Jun T" <tak...@kb...>
> To: "Ethan A Merritt via gnuplot-beta" <gnu...@li...>
> Date: 2023/06/09 金 12:34
> Subject: Re: Gnuplot 5.4.8 release
> 
> 
> 
> > 2023/06/08 2:06, Ethan A Merritt <me...@uw...> wrote:
> > 
> > Gnuplot 5.4.8
> 
> As many of you already know, the gnuplot Web sites are
> not updated recently:
> 
> Main gnuplot page:
> http://www.gnuplot.info, under "Version 5.4 (current)"
> it has a link to "Release 5.4.5 (October 2022)"
> and also to the "Release Notes" of 5.4.5.
> 
> The download page: http://www.gnuplot.info/download.html
> it says "The most recent release was 5.4.2 (June 2021)"
> 
> source forge:
> https://sourceforge.net/projects/gnuplot/files/gnuplot/
> the "Download Latest Version" button links to 5.4.7
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Gnuplot 5.4.8 release

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

> 2023/06/08 2:06, Ethan A Merritt <me...@uw...> wrote:
> 
> Gnuplot 5.4.8

As many of you already know, the gnuplot Web sites are
not updated recently:

Main gnuplot page:
http://www.gnuplot.info, under "Version 5.4 (current)"
it has a link to "Release 5.4.5 (October 2022)"
and also to the "Release Notes" of 5.4.5.

The download page: http://www.gnuplot.info/download.html
it says "The most recent release was 5.4.2 (June 2021)"

source forge:
https://sourceforge.net/projects/gnuplot/files/gnuplot/
the "Download Latest Version" button links to 5.4.7

Gnuplot 5.4.8 release

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

Gnuplot 5.4.8

I have bumped the reported version to 5.4.8 and uploaded a new tarball to
SourceForge.

This repairs an inconsistancy in the source and binary packages for 5.4.7,
in which

Windows binaries built from the source package identified as version
"5.4.7alpha"

rather than  "5.4.7".  There is no change to the gnuplot source between
5.4.7 and 5.4.8.

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

I apologize for introducing this inconsistancy when preparing the 5.4.7
relaase package.

    Ethan

Re: Gnuplot 5.4.7 release tarball available for testing

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

> 2023/06/02 3:08、Ethan A Merritt <me...@uw...>のメール:
> 
> - repackage 5.4.7 with the version number changed?
> 
> - release a version 5.4.8 that is identical to 5.4.7 except that it
> correctly reports its version number?
> 
> Either way may lead to some confusion.

How to fix this is up to you, but:

> The first option would change the check-sums for the tarball named
> gnuplot-5.4.7.tar.gz, which has led to concern in the past.

The release was just two weeks ago, but, yes, there is a *small*
possibility that a packager etc. has already created a spec/recipe
with the current check-sum.

> The second seems a bit odd if there are no actual changes or fixes
> between 7 and 8, but I guess it would not hurt anything.

I think most of users do not care if .7 is "skipped".

Re: Gnuplot 5.4.7 release tarball available for testing

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

Ugh.  I wonder how that slipped through?  My fault in any case.

I am not sure what is best

- repackage 5.4.7 with the version number changed?

- release a version 5.4.8 that is identical to 5.4.7 except that it
correctly reports its version number?

Either way may lead to some confusion.
The first option would change the check-sums for the tarball named
gnuplot-5.4.7.tar.gz, which has led to concern in the past.
The second seems a bit odd if there are no actual changes or fixes
between 7 and 8, but I guess it would not hurt anything.

   Ethan


On Wed, May 31, 2023 at 10:27 PM Jun T <tak...@kb...> wrote:

> > 2023/05/22 7:02、Tatsuro MATSUOKA via gnuplot-beta <gnu...@li...>のメール:
> >
> > I have uploaded Windows binary packages (exe, 7z. and zip).
>
> If I install by using gp547-win64-mingw.exe,
> "gnuplot 5.4 patchlevel 7alpha" is used for the name of
> the shortcuts on the Desktop and in the Start Menu.
>
> The same name ("alpha") is also used at the top of the
> help document (and maybe in other places).
>
> It works fine, but users may think that it is not
> the release version but an "alpha" version.
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...

Re: Gnuplot 5.4.7 release tarball available for testing

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

> 2023/05/22 7:02、Tatsuro MATSUOKA via gnuplot-beta <gnu...@li...>のメール:
> 
> I have uploaded Windows binary packages (exe, 7z. and zip).

If I install by using gp547-win64-mingw.exe,
"gnuplot 5.4 patchlevel 7alpha" is used for the name of
the shortcuts on the Desktop and in the Start Menu.

The same name ("alpha") is also used at the top of the
help document (and maybe in other places).

It works fine, but users may think that it is not
the release version but an "alpha" version.

Gnuplot 5.4.7 release

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

The gnuplot version 5.4.7 release is now available for download from
SourceForge, including Windows binaries.

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

There is no change from the testing version.

Release notes:

    https://gnuplot.sourceforge.net/ReleaseNotes_5_4_7.html

	Ethan

Re: Gnuplot 5.4.7 release tarball available for testing

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

I have uploaded Windows binary packages (exe, 7z. and zip).

Tatsuro


> ----- Original Message -----
> 
> From: "Tatsuro MATSUOKA via gnuplot-beta" <gnu...@li...>
> To: "pm" <mi...@ph...>
> Cc: "beta" <gnu...@li...>
> Date: 2023/05/21 日 13:59
> Subject: Re: Re: Gnuplot 5.4.7 release tarball available for testing
> 
> 
> Hi Peter
> 
> Preparation zip compressed binary is easy.
> I will prepare installer version, 7zip, and zip packages for 5.4.7 and later
> 
> Tatsuro
> 
> > ----- Original Message -----
> > 
> > From: "pm" <mi...@ph...>
> > To: "Tatsuro MATSUOKA" <tma...@ya...>
> > Cc: "beta" <gnu...@li...>
> > Date: 2023/05/19 金 23:52
> > Subject: Re: Gnuplot 5.4.7 release tarball available for testing
> > 
> > 
> >  	Hello Tatsuro,
> > 
> > > I have executed the test build on windows (MinGW64).
> > 
> > I see you upload the Windows binary also as a compressed 7z file. Would not be 
> > the traditional zip file more portable? Recently, I wanted to upgrade an older 
> > gnuplot on a Windows machine without admin privileges, but Windows 10 cannot 
> > unzip 7z natively.
> > 
> > Tech note: the EXAFS software Athena uses gnuplot with wxt terminal for 
> > drawing, but on that Windows 10 machine the cross of the ruler ("r" hotkey) is 
> > invisible (white cross on white background?), for all windows gnuplots 
> > downloadable as zip files. Thus peak distance measurement is difficult. I 
> > wonder whether it was a problem on only that machine or the problem is more 
> > frequent.
> > 
> > Greetings, Petr
> > 
> 
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Re: Gnuplot 5.4.7 release tarball available for testing

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

Hi Peter

Preparation zip compressed binary is easy.
I will prepare installer version, 7zip, and zip packages for 5.4.7 and later

Tatsuro

> ----- Original Message -----
> 
> From: "pm" <mi...@ph...>
> To: "Tatsuro MATSUOKA" <tma...@ya...>
> Cc: "beta" <gnu...@li...>
> Date: 2023/05/19 金 23:52
> Subject: Re: Gnuplot 5.4.7 release tarball available for testing
> 
> 
>  	Hello Tatsuro,
> 
> > I have executed the test build on windows (MinGW64).
> 
> I see you upload the Windows binary also as a compressed 7z file. Would not be 
> the traditional zip file more portable? Recently, I wanted to upgrade an older 
> gnuplot on a Windows machine without admin privileges, but Windows 10 cannot 
> unzip 7z natively.
> 
> Tech note: the EXAFS software Athena uses gnuplot with wxt terminal for 
> drawing, but on that Windows 10 machine the cross of the ruler ("r" hotkey) is 
> invisible (white cross on white background?), for all windows gnuplots 
> downloadable as zip files. Thus peak distance measurement is difficult. I 
> wonder whether it was a problem on only that machine or the problem is more 
> frequent.
> 
> Greetings, Petr
> 

Re: Gnuplot 5.4.7 release tarball available for testing

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> I have placed a pre-release tarball of 5.4.7 on the testing area of SourceForge
[…]
> If no problems are reported, I plan to use this for release of 5.4.7
> next week.

The Cygwin build has shown no anomalies.


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