gnuplot-beta Mailing List for gnuplot (Page 28)

In response to a gnuplot feature request, I added a wrapper in
gnuplot to find the width of the Voight profile by calling libcerf function
voigt_hwhm().

However on further evaluation this has turned out to be problematic.
The current libcerf source for this function deals badly with out-of-range
input.  It prints to stderr (problematic by itself) and then either
- returns an incorrect value
- calls exit(-1)

A call to exit() from a library routine is almost never a good thing to do,
since it prevents error-handling and possible recovery by the calling
program.  Limiting error reporting to a message on stderr also prevents
detection and recovery by the calling program.

I suggest that it would be preferable to return NaN whenever the
input is out of range or the function does not converge.

Alternatively libcerf could provide an error-check routine or status variable,
but then you would run into issues of thread-safety and so on.

I am hoping that the libcerf function can be improved in a subsequent
version, but for now I will consider implementing equivalent code
directly in gnuplot.

	Ethan

On Wednesday, 5 February 2020 19:49:06 PST Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> > On Thursday, 30 January 2020 21:32:02 PST Dima Kogan wrote:
> >> Hi. I just stumbled upon another bug-looking behavior.
> >> 
> >> The different point types aren't the same across terminals. There's no
> >> specific reason for that, right?
> > 
> > gnuplot> help pointttype
> > 
> > [...]
> > 
> >  The first 8 point types are shared by all terminals. Individual terminals
> >  may provide a much larger number of distinct point types. Use the `test`
> >  command to show what is provided by the current terminal settings.
> 
> Aha. Thanks for the note. I'd like to normalize this at least somewhat.
> The usual workflow for me (and probably for others) is:
> 
> 1. Do work, mess around with the data, look at it with an interactive
>    terminal (x11 in my case) as I go. Make plots lots of times
> 
> 2. Eventually I'm happy with what I have, I make a PDF and send it out
>    in an email
> 
> The expectation is that the PDF is the same thing I was seeing on the
> screen, and the inconsistent point types break that. I want to say that
> of the common terminals I looked at, the x11 terminal is the odd one
> out. If that's the case, any objections if I patch that?

It is not correct that the x11 terminal is the odd one out.

There is a lot of variation.  For example the postscript terminal
supports about 70 point types, which so far as I know are inherited
by other terminals that depend on it like epslatex.
The fig terminal supports about 60. 
The png terminal (and jpeg/gif/sixel) are limited to 13, like x11.
The tikz terminal, which would be another way to generate pdf output,
supports 15 but they are not the same ones as qt/wxt.

Some of the older terminals were even more limited, which was why
we only promised 8 distinct types, but those may be obsolete.

Furthermore the reason that x11 currently doesn't support
pentagon shapes to match qt and wxt pointtype 14/15 
is that they come out indistinguisable from ugly circles
so they are not very useful.

Possible approaches that might help your use case:

1)
We could revisit an old idea that was discussed years ago but never
fully worked out.   There could be a command
	set pointtype cycle N
that replaces any arbitrary pt M with pt (1 + M%N).
This command would work similarly to the current command
	set linetype cycle N
I.e. it forces a cycle of N point types even if the current terminal
can support more than N types.

Unfortunately the patches that circulated at that time don't work any more
because version 5 changed the way linetypes and associated properties are
handled.  It's not clear to me exactly how best to adapt them to version 5.

2)
You could approximate this idea by explicitly assigning point types
for as many linetypes as you are likely to use:
    max_pt = 8
    set for [i=1:100] linetype i pointtype (1 + (i-1) % max_pt)

3)
Use character point types instead of the default geometric shapes.
So long as you choose characters that are common to the fonts used
for the terminals you are switching between, this should make the
default sequence irrelevant.

	Ethan

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

> On Thursday, 30 January 2020 21:32:02 PST Dima Kogan wrote:
>> Hi. I just stumbled upon another bug-looking behavior.
>>
>> The different point types aren't the same across terminals. There's no
>> specific reason for that, right?
>
> gnuplot> help pointttype
>
> [...]
>  The first 8 point types are shared by all terminals. Individual terminals may
>  provide a much larger number of distinct point types. Use the `test` command
>  to show what is provided by the current terminal settings.

Aha. Thanks for the note. I'd like to normalize this at least somewhat.
The usual workflow for me (and probably for others) is:

1. Do work, mess around with the data, look at it with an interactive
   terminal (x11 in my case) as I go. Make plots lots of times

2. Eventually I'm happy with what I have, I make a PDF and send it out
   in an email

The expectation is that the PDF is the same thing I was seeing on the
screen, and the inconsistent point types break that. I want to say that
of the common terminals I looked at, the x11 terminal is the odd one
out. If that's the case, any objections if I patch that?

On Thursday, 30 January 2020 21:32:02 PST Dima Kogan wrote:
> Hi. I just stumbled upon another bug-looking behavior.
> 
> The different point types aren't the same across terminals. There's no
> specific reason for that, right?

gnuplot> help pointttype

[...]
 The first 8 point types are shared by all terminals. Individual terminals may
 provide a much larger number of distinct point types. Use the `test` command
 to show what is provided by the current terminal settings.

	Ethan



> 
> I do this:
> 
>   set terminal x11
>   test
> 
> Note that point type 18 is a solid square
> 
> Then I do this:
> 
>   set terminal qt
>   test
> 
> A solid square is now type 20. pdf works like qt, it looks like; I
> haven't tested any others. I have no cycles to fix it right now, but can
> put it on my list.
> 
> dima

On 1/31/20 9:49 AM, Henri Menke wrote:
> On 1/31/20 8:46 AM, Ethan A Merritt wrote:
>> On Wednesday, 29 January 2020 20:23:28 PST Henri Menke wrote:
>>> Dear list,
>>>
>>> In merge request #12 I propose the addition of the XDG base directory
>>> specification for configuration file paths.
>>>
>>>     https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/12/
>>>
>>> There is already some discussion on the ticket.  It seems that the
>>> overall opinion is in favor of this addition.  Is this correct?  If that
>>> is the case, could you please review the code?  After that I will write
>>> some words in the docs and we should be good to go.
>>
>> I notice that the filename is generated by a call to wordexp().
>> This is in POSIX-2001 but is not in the c99 standard, right?
>> The gnu docs say
>>   "This function is missing on some platforms: Mac OS X 10.3, OpenBSD 3.8,
>>   Minix 3.1.8, IRIX 5.3, Cygwin 1.5.x, mingw, MSVC 14, Interix 3.5, BeOS,
>>   Android 9.0."
>>
>> We have just barely got the gnuplot code base up to c99, so anything
>> beyond that should be protected by a feature test.  Is there an
>> autoconf macro for this?
>>
>> If the purpose is just to handle tilde expansion, can this dependence
>> be removed by replacing it with a call to gp_expand_tilde()?
> 
> You're right, wordexp is a POSIX function.  I will revise the code to
> use gp_expand_tilde instead.

I've updated the merge request and wrote some docs.

> Cheers, Henri
> 
>> 	Ethan
>>
>>
>>
>>

Hi. I just stumbled upon another bug-looking behavior.

The different point types aren't the same across terminals. There's no
specific reason for that, right?

I do this:

  set terminal x11
  test

Note that point type 18 is a solid square

Then I do this:

  set terminal qt
  test

A solid square is now type 20. pdf works like qt, it looks like; I
haven't tested any others. I have no cycles to fix it right now, but can
put it on my list.

dima

On 1/31/20 8:46 AM, Ethan A Merritt wrote:
> On Wednesday, 29 January 2020 20:23:28 PST Henri Menke wrote:
>> Dear list,
>>
>> In merge request #12 I propose the addition of the XDG base directory
>> specification for configuration file paths.
>>
>>     https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/12/
>>
>> There is already some discussion on the ticket.  It seems that the
>> overall opinion is in favor of this addition.  Is this correct?  If that
>> is the case, could you please review the code?  After that I will write
>> some words in the docs and we should be good to go.
> 
> I notice that the filename is generated by a call to wordexp().
> This is in POSIX-2001 but is not in the c99 standard, right?
> The gnu docs say
>   "This function is missing on some platforms: Mac OS X 10.3, OpenBSD 3.8,
>   Minix 3.1.8, IRIX 5.3, Cygwin 1.5.x, mingw, MSVC 14, Interix 3.5, BeOS,
>   Android 9.0."
> 
> We have just barely got the gnuplot code base up to c99, so anything
> beyond that should be protected by a feature test.  Is there an
> autoconf macro for this?
> 
> If the purpose is just to handle tilde expansion, can this dependence
> be removed by replacing it with a call to gp_expand_tilde()?

You're right, wordexp is a POSIX function.  I will revise the code to
use gp_expand_tilde instead.

Cheers, Henri

> 	Ethan
> 
> 
> 
> 

On Wednesday, 29 January 2020 20:23:28 PST Henri Menke wrote:
> Dear list,
> 
> In merge request #12 I propose the addition of the XDG base directory
> specification for configuration file paths.
> 
>     https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/12/
> 
> There is already some discussion on the ticket.  It seems that the
> overall opinion is in favor of this addition.  Is this correct?  If that
> is the case, could you please review the code?  After that I will write
> some words in the docs and we should be good to go.

I notice that the filename is generated by a call to wordexp().
This is in POSIX-2001 but is not in the c99 standard, right?
The gnu docs say
  "This function is missing on some platforms: Mac OS X 10.3, OpenBSD 3.8,
  Minix 3.1.8, IRIX 5.3, Cygwin 1.5.x, mingw, MSVC 14, Interix 3.5, BeOS,
  Android 9.0."

We have just barely got the gnuplot code base up to c99, so anything
beyond that should be protected by a feature test.  Is there an
autoconf macro for this?

If the purpose is just to handle tilde expansion, can this dependence
be removed by replacing it with a call to gp_expand_tilde()?

	Ethan

Dear list,

In merge request #12 I propose the addition of the XDG base directory
specification for configuration file paths.

    https://sourceforge.net/p/gnuplot/gnuplot-main/merge-requests/12/

There is already some discussion on the ticket.  It seems that the
overall opinion is in favor of this addition.  Is this correct?  If that
is the case, could you please review the code?  After that I will write
some words in the docs and we should be good to go.

Cheers, Henri

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

> You are right. The test for the cornerpoles flag was made a little too
> early. Fixed now.

Works now. Thanks!

On Sunday, 26 January 2020 22:11:46 PST Dima Kogan wrote:

> Thanks for working on this. The basic on/off appears to work. However,
> if I
> 
>   set border 31
>   unset cornerpoles
>   splot x
> 
> I'd expect the left vertical axis to still be rendered, but it isn't. I
> can take a look, but it'll take me a few days to get to this.

You are right.  The test for the cornerpoles flag was made a little too early.
Fixed now.

	Ethan

Ethan Merritt <eam...@gm...> writes:

> OK.  I have added
> 	{un}set cornerpoles
>
> It controls an on/off TBOOLEAN that is tested in exactly one place,
> just before these vertical lines are drawn in draw_3d_graphbox.

Thanks for working on this. The basic on/off appears to work. However,
if I

  set border 31
  unset cornerpoles
  splot x

I'd expect the left vertical axis to still be rendered, but it isn't. I
can take a look, but it'll take me a few days to get to this.

Thanks!

On Saturday, 25 January 2020 12:54:50 PST Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:
> >> On the other hand, looking up the bits one by one is inconvenient.
> >> It might be more user-friendly to add a keyword
> >> 
> >>      set border <bitmask> {{no} somethingdescriptive}
> > 
> > I would tend to call them 'corner poles', as they're meant to appear be
> > holding up the otherwise free-floating plotted surface at the corners, a
> > bit like the tent poles.
> 
> Yeah, I like that name; was thinking something along the same lines,
> actually.

That's better then anything I came up with.
OK.  I have added
	{un}set cornerpoles

It controls an on/off TBOOLEAN that is tested in exactly one place,
just before these vertical lines are drawn in draw_3d_graphbox.

	Ethan


> 
> > The syntax could be extended by a keyworded optional argument
> > 
> > 	set border
> > 	...
> > 	{{cornerpoles | cp} {default | <corners>}}
> > 
> > where the 'default' restores the current default: all four corner poles
> > are drawn, if applicable.  The corresponding bit mask value <corners>
> > would be 240, from 128+64+32+16.  I.e. for clarity it would use the same
> > bit positions as in the existing <integer> parameter for the full
> > 
> > Or 'cornerpoles' could become a new 'set' command of its own, or an
> > optional argument to 'set surface', given as it only applies if 'set
> > surface' is on.
> 
> I think it would be nice to manage two separate bit masks that use the
> same bit meanings:
> 
> - the current "border" bitmask
> - a new "cornerpoles" bitmask
> 
> I think this is what you're suggesting. If the "cornerpoles" bitmask
> isn't managed with a new "set cornerpoles", but uses an extension to
> "set border", what syntax are you proposing? How would you set a
> "border" mask A and a "cornerpoles" mask B? Like this?
> 
>   set border A cp B
> 
> Or with two separate calls?
> 
>   set border A
>   set border cp B
> 
> Not sure if one of these is what you had in mind. I think a separate
> "set" would be clearer:
> 
>   set border A
>   set cornerpoles B
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Hans-Bernhard Bröker <HBB...@t-...> writes:

>> On the other hand, looking up the bits one by one is inconvenient.
>> It might be more user-friendly to add a keyword
>>      set border <bitmask> {{no} somethingdescriptive}
>
> I would tend to call them 'corner poles', as they're meant to appear be
> holding up the otherwise free-floating plotted surface at the corners, a
> bit like the tent poles.

Yeah, I like that name; was thinking something along the same lines,
actually.


> The syntax could be extended by a keyworded optional argument
>
> 	set border
> 	...
> 	{{cornerpoles | cp} {default | <corners>}}
>
> where the 'default' restores the current default: all four corner poles
> are drawn, if applicable.  The corresponding bit mask value <corners>
> would be 240, from 128+64+32+16.  I.e. for clarity it would use the same
> bit positions as in the existing <integer> parameter for the full
>
> Or 'cornerpoles' could become a new 'set' command of its own, or an
> optional argument to 'set surface', given as it only applies if 'set
> surface' is on.

I think it would be nice to manage two separate bit masks that use the
same bit meanings:

- the current "border" bitmask
- a new "cornerpoles" bitmask

I think this is what you're suggesting. If the "cornerpoles" bitmask
isn't managed with a new "set cornerpoles", but uses an extension to
"set border", what syntax are you proposing? How would you set a
"border" mask A and a "cornerpoles" mask B? Like this?

  set border A cp B

Or with two separate calls?

  set border A
  set border cp B

Not sure if one of these is what you had in mind. I think a separate
"set" would be clearer:

  set border A
  set cornerpoles B

Am 21.01.2020 um 05:43 schrieb Ethan A Merritt:

> I have no objection to adding a corresonding flag bit (for all of them) in the
> "set border" command or even four flag bits (matching the four vertical edges
> of the full graph box).
> But the flag bit[s] would have to default to "on" for backwards compatibility.

That, I'm afraid, largely precludes the addition of control bits into 
the exisiting bit mask --- the default of that, 31, is guaranteed to be 
assumed by tons of existing scripts out there.  So unless the 
to-be-added bits had inverse meaning, they can't be in that mask.

> On the other hand, looking up the bits one by one is inconvenient.
> It might be more user-friendly to add a keyword
>      set border <bitmask> {{no} somethingdescriptive}

I would tend to call them 'corner poles', as they're meant to appear be 
holding up the otherwise free-floating plotted surface at the corners, a 
bit like the tent poles.

The syntax could be extended by a keyworded optional argument
	
	set border
	...
	{{cornerpoles | cp} {default | <corners>}}

where the 'default' restores the current default: all four corner poles 
are drawn, if applicable.  The corresponding bit mask value <corners> 
would be 240, from 128+64+32+16.  I.e. for clarity it would use the same 
bit positions as in the existing <integer> parameter for the full

Or 'cornerpoles' could become a new 'set' command of its own, or an 
optional argument to 'set surface', given as it only applies if 'set 
surface' is on.

On Monday, 20 January 2020 18:18:57 PST Dima Kogan wrote:
> Thanks for the explanation. That sounds very suprising to the user. Can
> we at the least document this behavior in "help border"? Ideally it'd be
> controllable in "set border" somewhere too. Is this something that
> wasn't done on purpose, or has nobody gotten around to it?

These lines are drawn unconditionally in the routine draw_3d_graphbox()
graph3d.c:2450ff

I have no objection to adding a corresonding flag bit (for all of them) in the
"set border" command or even four flag bits (matching the four vertical edges 
of the full graph box).
But the flag bit[s] would have to default to "on" for backwards compatibility. 

On the other hand, looking up the bits one by one is inconvenient.
It might be more user-friendly to add a keyword
    set border <bitmask> {{no} somethingdescriptive}

I can't think what to call these lines, however, so I have no good suggestion
for what that "somethingdescriptive" keyword might be.
"surface anchors"?   "drop lines"?   "partial edges"?
Ideas?

> 
> dima

-- 
Ethan A Merritt

Thanks for the explanation. That sounds very suprising to the user. Can
we at the least document this behavior in "help border"? Ideally it'd be
controllable in "set border" somewhere too. Is this something that
wasn't done on purpose, or has nobody gotten around to it?

dima

Am 17.01.2020 um 21:58 schrieb Dima Kogan:
> Hi. I found something odd. Not entirely sure it's a bug.
> 
> I'm running the latest gnuplot from git (as of today), but this behavior
> isn't new.

Far from it, actually.  This behaviour has been in gnuplot essentially
forever.

These short verticals are not the ones controlled by "set border".  The
easiest way to visualize this is actually not to try and _disable_ them,
but to turn them all _on_, and compare what you get:

	set xrange [-10:10] ; set yrange [-10:10]
	set zrange [-100:150]
	set multiplot layout 2,1
	set border 15 ; splot x*y
	set border 255 ; splot x*y
	unset multiplot

Note how the activated border verticals reach up all the way up to
z=150, whereas the default ones get only as far up as the surface
itself.  Which, coincidentally, is exactly how those are controlled: if
the corners of a plotted surface mesh lie point exactly in the corners
of the x-y range rectangle, splot draws verticals from the corners of
the xyplane up to those points.

To turn off these shorter verticals while keeping any borders on, you
have to bend them out of the vertical, i.e. make the x-y-plane corners
differ from the corner positions of the dataset.  For data splots, you
can grow out the axis ranges a bit; function splots may have to be
switched into parameteric mode (or pseudo data plots) to allow the same
change, e.g.:

	set parametric
	set urange [-9:9]; set vrange [-9:9]
	set border 15 ; splot u,v,u*v

Hi. I found something odd. Not entirely sure it's a bug.

I'm running the latest gnuplot from git (as of today), but this behavior
isn't new.

I can do this:

  splot x

I then get a plane, with the 4 borders of the xy plane drawn, and the
full-length left vertical axis, and for the other vertical axes, I get
lines from the xyplane up to where the data is.

I can do this:

  set border 0
  splot x

I then get just my plane, with none of the borders drawn at all. Works
with "unset border" too.

But let's say I just want the xy plane, with none of the vertical lines.
"help border" tells me I need to do this:

  set border 15
  splot x

This does NOT work to get rid of all the vertical lines. It removed the
full-length left vertical axis, but the lines from the xyplane up to the
data are still there. Why are those lines there? They aren't described
in "help border", even though "set border 0" does get rid of them. Is
there some other knob that lets you control that? If not, there should
probably be? Is it possible today to draw just the 4 xyplane borders?

Thanks!

Thanks!


-----Original Message-----
From: Ethan A Merritt <me...@uw...> 
Sent: Monday, January 13, 2020 7:02 PM
To: gnu...@li...
Cc: Ali Golkar <ag...@gm...>
Subject: Re: Checksums for gnuplot

On Monday, 13 January 2020 07:08:36 PST Ali Golkar wrote:
> Hello,
> 
> We have a researcher that is requesting to use gnuplot. As part of our 
> approval process we require a hash from the vendor/developer. Could 
> you provide the hash on the latest release of gnuplot? Md5,sha1,sha512 
> or really anything would work.

[~/gnuplot/tarballs] md5sum gnuplot-5.2.8.tar.gz 2df8767c7399bee57a96296d46b4d5fb  gnuplot-5.2.8.tar.gz [~/gnuplot/tarballs] sha512sum gnuplot-5.2.8.tar.gz 513dff15236dcb58c3c5471cdaa0713242787dbf30ef860c3f69152cb87c6392e4973caff5eb178707bbb84c78548e806b2920864a37686bce49425fbfdc4e8c
gnuplot-5.2.8.tar.gz

	Ethan


> 
> Thanks,
> Ali Golkar
> IT Security Analyst | ITSO
> Information Technology Services
> George Mason University
> 703-993-4970
> ag...@gm...<mailto:ag...@gm...>
> https://its.gmu.edu/


--
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

On Monday, 13 January 2020 07:08:36 PST Ali Golkar wrote:
> Hello,
> 
> We have a researcher that is requesting to use gnuplot. As part of our
> approval process we require a hash from the vendor/developer. Could you
> provide the hash on the latest release of gnuplot? Md5,sha1,sha512 or
> really anything would work.

[~/gnuplot/tarballs] md5sum gnuplot-5.2.8.tar.gz
2df8767c7399bee57a96296d46b4d5fb  gnuplot-5.2.8.tar.gz
[~/gnuplot/tarballs] sha512sum gnuplot-5.2.8.tar.gz
513dff15236dcb58c3c5471cdaa0713242787dbf30ef860c3f69152cb87c6392e4973caff5eb178707bbb84c78548e806b2920864a37686bce49425fbfdc4e8c  
gnuplot-5.2.8.tar.gz

	Ethan


> 
> Thanks,
> Ali Golkar
> IT Security Analyst | ITSO
> Information Technology Services
> George Mason University
> 703-993-4970
> ag...@gm...<mailto:ag...@gm...>
> https://its.gmu.edu/


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Hello,

We have a researcher that is requesting to use gnuplot. As part of our approval process we require a hash from the vendor/developer. Could you provide the hash on the latest release of gnuplot? Md5,sha1,sha512 or really anything would work.

Thanks,
Ali Golkar
IT Security Analyst | ITSO
Information Technology Services
George Mason University
703-993-4970
ag...@gm...<mailto:ag...@gm...>
https://its.gmu.edu/

	gnuplot stable version
	_____________________

Version 5.2.8 went out earlier this month.

Initial release of 5.4 is projected for Spring 2020.
I have created branch-5-4-stable for staging of release candidates.

	gnuplot development
	____________________

Development continues in the main branch ("master") in the git repository.
The identifying version for the development branch has been bumped
from 5.3 to 5.5 so that it stays ahead of the stable branch.

	Ethan

Dear Ethan et al.,

Thank you. The OSX (Mac) package for 5.2.8 is available in the usual place (
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
).
Side note: please update http://gnuplot.info/download.html (where it
mentions 5.2.7 and "May 2019", twice)

Regards,

Erik


On Sun, Dec 1, 2019 at 10:44 PM Ethan Merritt (UW) <me...@uw...> wrote:

> The gnuplot release 5.2.8 source tarball is ready and can be downloaded
> from
>
>
> https://sf.net/projects/gnuplot/files/gnuplot/5.2.8/gnuplot-5.2.8.tar.gz
>
> There is not much in this update other than minor bug fixes,
> mostly addressing individual terminal quirks.
>
> This is the final planned release for gnuplot version 5.2.
>
> I will create a new 5-4-stable branch of the git repository and
> re-label the development trunk as 5.5.
>
> Expect a 5.4.rc1 early next year, to be followed by however many
> -rcX iterations are necessary to get a solid 5.4 for Spring 2020.
>
>
> Changes in 5.2.8
> ================
> * CHANGE user-visible GPVAL_TERM_HCHAR GPVAL_TERM_VCHAR (help debug font
> issues)
> * CHANGE placement of ylabel (compromise 5.2.7 and earlier versions) (Bug
> #2181)
> * CHANGE make strstrt() aware of UTF8, e.g. strstrt("αβγ5", "5") returns 4
> * FIX "set timestamp" from "save" must not include a justification (Bug
> #2178)
> * FIX set cntrparam levels increment <base>, <factor> for logscale z (Bug
> #2183)
> * FIX character pointtypes should inherit plot coloring like normal
> pointtypes
> * FIX bad autoscaling of linked y2 axis (Bug #2186)
> * FIX prevent infinite loop from unbounded interation in a non-data plot
> command
> * FIX dimensions reported by "stats matrix every" (Bug #2189)
> * FIX extent of boxplot whiskers could be off by one point (Bug #2106)
> * FIX mix unbounded iteration and functions in a single plot command (Bug
> #2201)
> * FIX reverse history search with readline=builtin (Bug #2209)
> * FIX qt: suppress off-by-one ysize (Bug #1759)
> * FIX cairo: suppress off-by-one ysize (Bug #1759)
> * FIX gd: apply alpha to brushstroke lines (Bug #2117)
> * FIX tikz: fixes to accommodate lua 5.3 and newer pgf
> * FIX wxt: ExportToFile widget disabled in persist mode (Bug #2185)
> * FIX qt: handling of modifier keys (ctrl alt shift) for keyboard events
> * FIX wxt: handling of modifier keys (ctrl alt shift) for keyboard events
> * FIX fig: dashtype "solid" was not passed through correctly to transfig
> * FIX gd: incorrect line spacing of multiline label (Bug #2215)
>
> Note:
>   Windows binaries will be delayed; please be patient.
>
>         cheers, and happy plotting
>
>                 Ethan
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

The gnuplot release 5.2.8 source tarball is ready and can be downloaded from

    https://sf.net/projects/gnuplot/files/gnuplot/5.2.8/gnuplot-5.2.8.tar.gz

There is not much in this update other than minor bug fixes,
mostly addressing individual terminal quirks.

This is the final planned release for gnuplot version 5.2.

I will create a new 5-4-stable branch of the git repository and
re-label the development trunk as 5.5.

Expect a 5.4.rc1 early next year, to be followed by however many
-rcX iterations are necessary to get a solid 5.4 for Spring 2020.


Changes in 5.2.8
================
* CHANGE user-visible GPVAL_TERM_HCHAR GPVAL_TERM_VCHAR (help debug font issues)
* CHANGE placement of ylabel (compromise 5.2.7 and earlier versions) (Bug #2181)
* CHANGE make strstrt() aware of UTF8, e.g. strstrt("αβγ5", "5") returns 4
* FIX "set timestamp" from "save" must not include a justification (Bug #2178)
* FIX set cntrparam levels increment <base>, <factor> for logscale z (Bug #2183)
* FIX character pointtypes should inherit plot coloring like normal pointtypes
* FIX bad autoscaling of linked y2 axis (Bug #2186)
* FIX prevent infinite loop from unbounded interation in a non-data plot command
* FIX dimensions reported by "stats matrix every" (Bug #2189)
* FIX extent of boxplot whiskers could be off by one point (Bug #2106)
* FIX mix unbounded iteration and functions in a single plot command (Bug #2201)
* FIX reverse history search with readline=builtin (Bug #2209)
* FIX qt: suppress off-by-one ysize (Bug #1759)
* FIX cairo: suppress off-by-one ysize (Bug #1759)
* FIX gd: apply alpha to brushstroke lines (Bug #2117)
* FIX tikz: fixes to accommodate lua 5.3 and newer pgf
* FIX wxt: ExportToFile widget disabled in persist mode (Bug #2185)
* FIX qt: handling of modifier keys (ctrl alt shift) for keyboard events
* FIX wxt: handling of modifier keys (ctrl alt shift) for keyboard events
* FIX fig: dashtype "solid" was not passed through correctly to transfig
* FIX gd: incorrect line spacing of multiline label (Bug #2215)

Note:
  Windows binaries will be delayed; please be patient.

	cheers, and happy plotting

		Ethan