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

Re: OK to put out an -rc2 for version 5.4?

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

On Saturday, 6 June 2020 00:26:27 PDT ASSI wrote:
> Ethan A Merritt writes:
> > There have been no major changes since -rc1, but a few of them touch
> > the build + packaging pathway so it would be good to test them.
> 
> FWIW, I have seen no problems with RC1 on Cygwin.
> 
> I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
> problem isn't properly solved 

Thank you for reminding me of that problem.
I reviewed the original report and the trail of issues filed with the
Cygwin and Qt upstreams.  It seems that nothing came of either after
the first flurry of investigation.
   
However one point was raised which you might know more of.
As I understand it, the original diagnosis was that Cygwin was using
named pipes to emulate unix sockets. But that was corrected by 
Corinna Vinschen, who said that Cygwin was moving towards using
named pipes but was [at that time] using  loopback IPv4 sockets to 
implement AF_UNIX sockets.  That was more than a year ago.
Has the situation changed?  If switching to named pipes would
resolve this problem and the work is planned anyhow, perhaps it is worth
prodding to see how close to completion it might be?

> I'd thought I should maybe package wxt
> instead (which I recently got working).  However, wxt doesn't produce
> its own executable and pulls in an enormous amount of libraries that
> many people don't want installed.  Is there some build option that I may
> have missed to separate the wxt terminal out (like qt and X11) so it can
> be put in its own package and the non-GUI gnuplot can remain as lean as
> it used to be?

No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
driver.   About 10 years ago there was some work to create one because at the
time the inboard driver did not work on OSX, but it never reached completion
and also I think the OSX problem resolved itself.
   https://sourceforge.net/p/gnuplot/patches/380/

The thing is, even if you resurrected that patch series to create an outboard
wxt terminal I worry that you would run into exactly the same problem that
is hitting the outboard Qt driver:  you need an inter-process communication
socket, and that seems to be where the Cygwin options are shaky.

Nevertheless, if you want to organize or delegate someone to work on
an outboard wxt terminal driver I'd be happy to kibbutz from the sidelines.

	best,

		Ethan

> Regards
> Achim.
> 

Re: OK to put out an -rc2 for version 5.4?

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

Ethan A Merritt writes:
> There have been no major changes since -rc1, but a few of them touch
> the build + packaging pathway so it would be good to test them.

FWIW, I have seen no problems with RC1 on Cygwin.

I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
problem isn't properly solved I'd thought I should maybe package wxt
instead (which I recently got working).  However, wxt doesn't produce
its own executable and pulls in an enormous amount of libraries that
many people don't want installed.  Is there some build option that I may
have missed to separate the wxt terminal out (like qt and X11) so it can
be put in its own package and the non-GUI gnuplot can remain as lean as
it used to be?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

5.4.rc2 second release candidate for gnuplot version 5.4

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

I have placed a tarball for 5.4.rc2 on SourceForge

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download

 Release Notes date: 04-Jun-2020

* Changes between -rc1 and -rc2
        o faster response to piped input on Windows (Bug #2204)
        o "splot with boxes" failed to recognize "fc palette" in -rc1
        o repair several problems with parallel axis plots (Bug #2294)
        o minor changes to dumb.trm, pixmap handling
        o -rc1 failed to act on "with labels rotate by <ang>" (Bug #2264)
        o \n _not_ stripped from string returned by backquoted shell command
        o fix autoscaling of boxplots
        o new function palette(z) returns packed RGB representation
        o lua/tikz terminal applies alpha channel to point symbols

Can someone comment on this issue - is it reproducible?
    Bug #2261 Text Size Depends on Windows Scale and Layout Setting
    https://sourceforge.net/p/gnuplot/bugs/2261/

Any other known issues?

	Ethan

Re: GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

On Fri, 5 Jun 2020, Ethan A Merritt wrote:

> On Friday, 5 June 2020 13:25:18 PDT Allin Cottrell wrote:
>> On Fri, 5 Jun 2020, Ethan A Merritt wrote:
>>
>>> On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
>>>> I'm seeing something that puzzles me. I create a plot using this
>>>> term line:
>>>>
>>>> set term pngcairo size 762,600
>>>>
>>>> Now I'm interested in retrieving the size of the PNG (which the
>>>> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
>>>> get
>>>>
>>>> GPVAL_TERM_XSIZE = 15240
>>>> GPVAL_TERM_YSIZE = 12000
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> and on division by 20 I get the size back OK. But using 5.2.8 I get
>>>>
>>>> GPVAL_TERM_XSIZE = 15220
>>>> GPVAL_TERM_YSIZE = 11980
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> giving 761 x 599 on division by 20.
>>>>
>>>> Is this inadvertant or is there a reason for the difference?
>>>
>>> 600 pixels on y numbered from 0 to 599.
>>> 762 pixels on x numbered from 0 to 761.
>>>
>>> The internal variables are
>>>  term->xmax
>>>  term->ymax
>>>
>>> It is perhaps unfortunate that the exported versions are named
>>> "size" rather than "max".  This change fixed a long history of bug
>>> reports of asymmetry in the left/right top/bottom borders of
>>> pixel-based output plots.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
>>> Author: Ethan A Merritt <merritt@u.washington.edu>
>>> Date:   Fri Jun 8 10:42:22 2018 -0700
>>>
>>>    Reconcile cairo terminal pixel coordinates and floating point coordinates.
>>>
>>>    The floating point coordinate space used internally by the terminal
>>>    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
>>>    Simply casting to (int) produces a bottom-of-screen y coordinate that
>>>    is one too large and hence is not drawn.  Similarly the right-of-screen
>>>    maximum x coordinate. Now we report one pixel smaller dimensions back
>>>    to the core code via term->xmax and term->ymax while retaining the full
>>>    canvas size internally to retain the oversampling boost in precision.
>>>    This affects all the cairo terminal variants including wxt.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>> Thanks, Ethan. Not crucial, but do you know what was the first
>> release to incorporate this change? (I tried to figure this out
>> myself but failed.)
>>
>> Allin
>
> First appeared in 5.2.8, although it had been active in the 
> development version for 18 months at that point.

Thanks again! Good to know for sure.

Allin Cottrell

Re: GPVAL_TERM_XSIZE behavior?

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

On Friday, 5 June 2020 13:25:18 PDT Allin Cottrell wrote:
> On Fri, 5 Jun 2020, Ethan A Merritt wrote:
> 
> > On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
> >> I'm seeing something that puzzles me. I create a plot using this
> >> term line:
> >>
> >> set term pngcairo size 762,600
> >>
> >> Now I'm interested in retrieving the size of the PNG (which the
> >> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
> >> get
> >>
> >> GPVAL_TERM_XSIZE = 15240
> >> GPVAL_TERM_YSIZE = 12000
> >> GPVAL_TERM_SCALE = 20
> >>
> >> and on division by 20 I get the size back OK. But using 5.2.8 I get
> >>
> >> GPVAL_TERM_XSIZE = 15220
> >> GPVAL_TERM_YSIZE = 11980
> >> GPVAL_TERM_SCALE = 20
> >>
> >> giving 761 x 599 on division by 20.
> >>
> >> Is this inadvertant or is there a reason for the difference?
> >
> > 600 pixels on y numbered from 0 to 599.
> > 762 pixels on x numbered from 0 to 761.
> >
> > The internal variables are
> >  term->xmax
> >  term->ymax
> >
> > It is perhaps unfortunate that the exported versions are named
> > "size" rather than "max".  This change fixed a long history of bug
> > reports of asymmetry in the left/right top/bottom borders of
> > pixel-based output plots.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
> > Author: Ethan A Merritt <merritt@u.washington.edu>
> > Date:   Fri Jun 8 10:42:22 2018 -0700
> >
> >    Reconcile cairo terminal pixel coordinates and floating point coordinates.
> >
> >    The floating point coordinate space used internally by the terminal
> >    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
> >    Simply casting to (int) produces a bottom-of-screen y coordinate that
> >    is one too large and hence is not drawn.  Similarly the right-of-screen
> >    maximum x coordinate. Now we report one pixel smaller dimensions back
> >    to the core code via term->xmax and term->ymax while retaining the full
> >    canvas size internally to retain the oversampling boost in precision.
> >    This affects all the cairo terminal variants including wxt.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> Thanks, Ethan. Not crucial, but do you know what was the first 
> release to incorporate this change? (I tried to figure this out 
> myself but failed.)
> 
> Allin

First appeared in 5.2.8, although it had been active in the development version
for 18 months at that point.

	Ethan

Re: GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

On Fri, 5 Jun 2020, Ethan A Merritt wrote:

> On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
>> I'm seeing something that puzzles me. I create a plot using this
>> term line:
>>
>> set term pngcairo size 762,600
>>
>> Now I'm interested in retrieving the size of the PNG (which the
>> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
>> get
>>
>> GPVAL_TERM_XSIZE = 15240
>> GPVAL_TERM_YSIZE = 12000
>> GPVAL_TERM_SCALE = 20
>>
>> and on division by 20 I get the size back OK. But using 5.2.8 I get
>>
>> GPVAL_TERM_XSIZE = 15220
>> GPVAL_TERM_YSIZE = 11980
>> GPVAL_TERM_SCALE = 20
>>
>> giving 761 x 599 on division by 20.
>>
>> Is this inadvertant or is there a reason for the difference?
>
> 600 pixels on y numbered from 0 to 599.
> 762 pixels on x numbered from 0 to 761.
>
> The internal variables are
>  term->xmax
>  term->ymax
>
> It is perhaps unfortunate that the exported versions are named
> "size" rather than "max".  This change fixed a long history of bug
> reports of asymmetry in the left/right top/bottom borders of
> pixel-based output plots.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
> Author: Ethan A Merritt <merritt@u.washington.edu>
> Date:   Fri Jun 8 10:42:22 2018 -0700
>
>    Reconcile cairo terminal pixel coordinates and floating point coordinates.
>
>    The floating point coordinate space used internally by the terminal
>    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
>    Simply casting to (int) produces a bottom-of-screen y coordinate that
>    is one too large and hence is not drawn.  Similarly the right-of-screen
>    maximum x coordinate. Now we report one pixel smaller dimensions back
>    to the core code via term->xmax and term->ymax while retaining the full
>    canvas size internally to retain the oversampling boost in precision.
>    This affects all the cairo terminal variants including wxt.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thanks, Ethan. Not crucial, but do you know what was the first 
release to incorporate this change? (I tried to figure this out 
myself but failed.)

Allin

Re: GPVAL_TERM_XSIZE behavior?

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

On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
> I'm seeing something that puzzles me. I create a plot using this 
> term line:
> 
> set term pngcairo size 762,600
> 
> Now I'm interested in retrieving the size of the PNG (which the 
> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I 
> get
> 
> GPVAL_TERM_XSIZE = 15240
> GPVAL_TERM_YSIZE = 12000
> GPVAL_TERM_SCALE = 20
> 
> and on division by 20 I get the size back OK. But using 5.2.8 I get
> 
> GPVAL_TERM_XSIZE = 15220
> GPVAL_TERM_YSIZE = 11980
> GPVAL_TERM_SCALE = 20
> 
> giving 761 x 599 on division by 20.
> 
> Is this inadvertant or is there a reason for the difference?

600 pixels on y numbered from 0 to 599.
762 pixels on x numbered from 0 to 761.

The internal variables are
  term->xmax
  term->ymax

It is perhaps unfortunate that the exported versions are named
"size" rather than "max".  This change fixed a long history of bug
reports of asymmetry in the left/right top/bottom borders of
pixel-based output plots.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%
commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
Author: Ethan A Merritt <merritt@u.washington.edu>
Date:   Fri Jun 8 10:42:22 2018 -0700

    Reconcile cairo terminal pixel coordinates and floating point coordinates.
    
    The floating point coordinate space used internally by the terminal
    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
    Simply casting to (int) produces a bottom-of-screen y coordinate that
    is one too large and hence is not drawn.  Similarly the right-of-screen
    maximum x coordinate. Now we report one pixel smaller dimensions back
    to the core code via term->xmax and term->ymax while retaining the full
    canvas size internally to retain the oversampling boost in precision.
    This affects all the cairo terminal variants including wxt.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%



	Ethan

GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

I'm seeing something that puzzles me. I create a plot using this 
term line:

set term pngcairo size 762,600

Now I'm interested in retrieving the size of the PNG (which the 
venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I 
get

GPVAL_TERM_XSIZE = 15240
GPVAL_TERM_YSIZE = 12000
GPVAL_TERM_SCALE = 20

and on division by 20 I get the size back OK. But using 5.2.8 I get

GPVAL_TERM_XSIZE = 15220
GPVAL_TERM_YSIZE = 11980
GPVAL_TERM_SCALE = 20

giving 761 x 599 on division by 20.

Is this inadvertant or is there a reason for the difference?

Allin Cottrell

Re: splot contours: how to silence a bogus warning?

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

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

>     plot $D1 matrix nosurface,  $D2 using 1:2:3 notitle nocontour

YES! "nocontour" is the magic word. Thank you!

Re: splot contours: how to silence a bogus warning?

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

On Tuesday, 19 May 2020 22:52:48 PDT Dima Kogan wrote:
> Hi. I'm probably doing this wrong, but in case I'm not, can somebody
> give me a pointer?
> 
> I'm making an splot with "set view map". There're two things in the
> splot command:
> 
> - gridded data. this is for contours
> 
> - a line. the is just another thing to plot; no contours needed or
>   wanted
> 
> Gnuplot really wants to contour everything, so it gives me a warning
> aobut not being able to contour the line:
> 
>   "/tmp/tst.gp" line 15: warning: Cannot contour non grid data. Please use "set dgrid3d".
> 
> The plot works otherwise. How can I tell gnuplot what specifically I
> want contoured?

    set style data lines
    set contour
    plot $D1 matrix nosurface,  $D2 using 1:2:3 notitle nocontour

	Ethan


> A demo script:
> 
> 
> set view map
> set contour surface
> set cntrparam levels incremental 10,1,20
> splot '-' matrix with lines nosurface ,'-' using 1:2:3 notitle with lines lw 3
> 21.116659897839263 19.791039827138583 18.227675240475808
> 17.237090114458017 16.05638264955801 14.720006247692512
> 13.875609237866147 12.820842598325108 11.685987645475555
> 
> e
> .539 .853 0.0
> 0 .1706 0.0
> 0 .2986 0.0
> e
> 
> 
> Thanks!
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


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

splot contours: how to silence a bogus warning?

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

Hi. I'm probably doing this wrong, but in case I'm not, can somebody
give me a pointer?

I'm making an splot with "set view map". There're two things in the
splot command:

- gridded data. this is for contours

- a line. the is just another thing to plot; no contours needed or
  wanted

Gnuplot really wants to contour everything, so it gives me a warning
aobut not being able to contour the line:

  "/tmp/tst.gp" line 15: warning: Cannot contour non grid data. Please use "set dgrid3d".

The plot works otherwise. How can I tell gnuplot what specifically I
want contoured? A demo script:


set view map
set contour surface
set cntrparam levels incremental 10,1,20
splot '-' matrix with lines nosurface ,'-' using 1:2:3 notitle with lines lw 3
21.116659897839263 19.791039827138583 18.227675240475808
17.237090114458017 16.05638264955801 14.720006247692512
13.875609237866147 12.820842598325108 11.685987645475555

e
.539 .853 0.0
0 .1706 0.0
0 .2986 0.0
e


Thanks!

OK to put out an -rc2 for version 5.4?

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

I would like to give people an -rc2 to test.

There have been no major changes since -rc1, but a few of them touch
the build + packaging pathway so it would be good to test them.

Bastian:  Did you figure out what the problem was with libgd + Windows 10?

Can someone comment on this issue - is it reproducible?
    Bug #2261 Text Size Depends on Windows Scale and Layout Setting
    https://sourceforge.net/p/gnuplot/bugs/2261/

Any other known issues?

	Ethan

Re: Default fillstyle for 'set rectangle' is slightly wrong

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

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

> The place where I can see it is a bit unclear is that "help set style fill"
> only says "see also 'set style rectangle'", which isn't much of a warning.
>
> I have now expanded that for 5.4 to read:
>
>    Note that there is a separate default fill style for rectangle objects.
>    See `set style rectangle`.
>
> Do you think that is OK, or is there something more or some additional
> place it should be expanded?

Yeah, I think that's a lot better. Can we replace "rectangle objects".
With "objects defined with 'set object rectangle'"? Otherwise it's not
clear whether we're talking about some generic 'object' or not.

Thanks much.

Re: Default fillstyle for 'set rectangle' is slightly wrong

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

On Saturday, 2 May 2020 15:01:57 PDT Dima Kogan wrote:
> Hi. Thanks for the context.
> 
> I don't entirely follow the explanation, though. You're saying that "set
> style fill" kicks in when objects come from the plot and "set style
> rectangle" kicks in when objects come from "set object rectangle"?

Yes.

> My general feeling is that breaking backwards compatibility should be
> avoided at all costs, and we probably should leave this the way it is.
> After all, it has been this way, and you hear complaints very rarely.
> 
> One thing we SHOULD change is the docs. The impetus for this thread was
> that I was apparently looking at the wrong part of the docs, which told
> me the wrong thing. 

The information _is_ in there, but I can try to make it clearer. 

> If the interpretation above is correct, then "help
> set style rectangle" can say
> 
>   The default values correspond to solid fill with the background color
>   and a black border. Note that this default applies to rectangles
>   created with "set object". Rectangles from data are controlled by "set
>   style fill", and are empty by default.
> 
> Or something like that. Is that reasonable?

It already does say something like that, doesn't it?
The current text (version 5.2.8) reads

 Rectangles defined with the `set object` command can have individual styles.
 However, if the object is not assigned a private style then it inherits a
 default that is taken from the `set style rectangle` command.
 [syntax and examples snipped]
 The default values correspond to solid fill with the background color and a
 black border.

The place where I can see it is a bit unclear is that "help set style fill"
only says "see also 'set style rectangle'", which isn't much of a warning.

I have now expanded that for 5.4 to read:

   Note that there is a separate default fill style for rectangle objects.
   See `set style rectangle`.

Do you think that is OK, or is there something more or some additional
place it should be expanded?

	Ethan

Re: Default fillstyle for 'set rectangle' is slightly wrong

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

Hi. Thanks for the context.

I don't entirely follow the explanation, though. You're saying that "set
style fill" kicks in when objects come from the plot and "set style
rectangle" kicks in when objects come from "set object rectangle"?

My general feeling is that breaking backwards compatibility should be
avoided at all costs, and we probably should leave this the way it is.
After all, it has been this way, and you hear complaints very rarely.

One thing we SHOULD change is the docs. The impetus for this thread was
that I was apparently looking at the wrong part of the docs, which told
me the wrong thing. If the interpretation above is correct, then "help
set style rectangle" can say

  The default values correspond to solid fill with the background color
  and a black border. Note that this default applies to rectangles
  created with "set object". Rectangles from data are controlled by "set
  style fill", and are empty by default.

Or something like that. Is that reasonable?

Re: Default fillstyle for 'set rectangle' is slightly wrong

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

On Friday, 1 May 2020 15:38:15 PDT Ethan A Merritt wrote:
> On Friday, 1 May 2020 14:04:22 PDT Dima Kogan wrote:
> > Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
> > But this isn't what's happening:
> > 
> >   set grid
> >   set object rectangle from 0,0 to 1,1
> >   plot [-1:2][-1:2] x
> > 
> > Note that the grid lines do not show up behind the rectangle. If I
> > explicitly add "fillstyle empty" to the rectangle definition, you get
> > the transparent rectangle.
> 
> Going way back to the initial implementation of rectangle as objects,
> the default was "solid fill with background color", which is not the
> same thing as "empty". This is true for all object types.
> 
> gnuplot> help set style rectangle
>  Rectangles defined with the `set object` command can have individual styles.
>  However, if the object is not assigned a private style then it inherits a
>  default that is taken from the `set style rectangle` command.
>  [snip]
>  The default values correspond to solid fill with the background color and a
>  black border. 
> 
> The idea was to have separate global fill styles for each object type.
> In retrospect that might not have been the best idea, but that's what we have.
> In retrospect it might also have been better to have all global fill styles
> start with the same default.
> 
> What do you think?
> Is it worth breaking backward compatibility to change this?
> I'm inclined to say yes, but only in the development verion, not for 5.4.   
> Do away with separate fillstyles?
> Keep them but give them all the same default properties?

After some thought, I'm coming around to thinking that if we do change it,
5.4 would be a good time.   It could be a bullet point in the Release Notes

o CHANGE - objects (rectangles, circles, etc) now default to fillstyle "empty"
                    rather than solid fill with background color.   

	Ethanμ

Re: Default fillstyle for 'set rectangle' is slightly wrong

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

On Friday, 1 May 2020 14:04:22 PDT Dima Kogan wrote:
> Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
> But this isn't what's happening:
> 
>   set grid
>   set object rectangle from 0,0 to 1,1
>   plot [-1:2][-1:2] x
> 
> Note that the grid lines do not show up behind the rectangle. If I
> explicitly add "fillstyle empty" to the rectangle definition, you get
> the transparent rectangle.

Going way back to the initial implementation of rectangle as objects,
the default was "solid fill with background color", which is not the
same thing as "empty". This is true for all object types.

gnuplot> help set style rectangle
 Rectangles defined with the `set object` command can have individual styles.
 However, if the object is not assigned a private style then it inherits a
 default that is taken from the `set style rectangle` command.
 [snip]
 The default values correspond to solid fill with the background color and a
 black border. 

The idea was to have separate global fill styles for each object type.
In retrospect that might not have been the best idea, but that's what we have.
In retrospect it might also have been better to have all global fill styles
start with the same default.

What do you think?
Is it worth breaking backward compatibility to change this?
I'm inclined to say yes, but only in the development verion, not for 5.4.   
Do away with separate fillstyles?
Keep them but give them all the same default properties?


There is another very messy historical artifact about fill styles that
goes with this and affects many many places in the code. 

Example:     plot FOO with candlesticks lt 3

At the time it seemed reasonable that if the fillstyle was "empty",
this meant to use the color of linetype 3 for the border of the
candlestick boxes. But if the fillstyle was "solid" it meant use the
color of linetype 3 for the fill area, not the border.  See the problem?
Then it got worse when "set fillstyle" got a bordercolor property
and worse again when linetype and linecolor became differentiated.

This adds complexity and non-obvious side effects in a lot of
places.  When the code sees "plot ... with boxes lc foo", where should
it store that color? 
  As the linecolor of the plot?
  As the bordercolor of the fillstyle for that plot?
  As the fill color for the fillstyle for that plot?
Right now it's a messy combination of all three options depending
on whether the fillstyle is EMPTY or SOLID and depending on whether
we are in pm3d or hidden3d mode. Ugh.

It would be much nicer to rationalize where colors are stored, even
if it means adding yet more places to the plot structure.
But that would be quite a lot of work and likely to generate a trail
of bug reports because it touches the code in so many places.
Maybe a wishlist item for version 6?

	Ethan

Default fillstyle for 'set rectangle' is slightly wrong

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

Hi. The docs (help fillstyle) say that the default fillstyle is "empty".
But this isn't what's happening:

  set grid
  set object rectangle from 0,0 to 1,1
  plot [-1:2][-1:2] x

Note that the grid lines do not show up behind the rectangle. If I
explicitly add "fillstyle empty" to the rectangle definition, you get
the transparent rectangle.

Thanks!

Re: Fast image markup?

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

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

> On Monday, 13 April 2020 11:08:01 PDT Dima Kogan wrote:
>
>> >> I tried big images too. I THINK they work, but it's still really slow
>> >> compared to any image viewer. Is that expected? Should it be faster than
>> >> what "with rgbimage" does?
>> >
>> > "slow" when doing what?  rotating in 3D?
>> > Can you do that in a normal image viewer?
>>
>> Just the simplest usage: plot an image with some annotations. No 3d or
>> any transformations of anything. Compared to image viewers the speed
>> difference isn't subtle.
>
> I may be misunderstanding what you are doing (quite possible).
>
> For me using a large image (say a 1365x1024 jpg "wallpaper" photo)
> as a background introduces no noticeable delay at all using the wxt
> terminal.  Even for 3D rotation the response is instantaneous:
>
>     set term wxt size 1500,1000
>     set pixmap 1 at screen 0,0 size screen 1,1 behind '~/images/wallpaper/p1040193.jpg'
>     splot x*y with pm3d
>     [rotate/zoom/translate with mouse as normal]

That's a really good data point. Thanks. I got side-tracked into
something else, but let me come back to this later with some benchmarks,
and we can compare. It'd be great if there was something specific about
my setup that's slowing it down.

Re: geographic plotting

[Allin C. <cot...@wf...>]

On Tue, 14 Apr 2020, Ethan A Merritt wrote:

> On Monday, 13 April 2020 13:14:54 PDT Allin Cottrell wrote:
>> On Fri, 6 Mar 2020, Ethan A Merritt wrote:
>>
>> [a propos Manfred Schwarb's suggestion of using GeoJSON files
>> for geographic plotting in gnuplot]
>>
>>> Good call.  Geojson looks quite promising.
>>> A real parser should be easy, but even a quick pass through sed
>>> or a text editor makes it usable.
>>> I have posted a proof-of-principle example using US state boundary
>>> data from a sample file on the geojson development site:
>>>
>>>  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
>>
>> Thanks for the example, Ethan.
>>
>> I've recently returned to this issue, exploring the shapefiles
>> option. I've written some relevant utilities in C, designed to link
>> against Frank Warmerdam's lipshape. (I'll be happy to share these
>> once they're better tested.) With their help I've managed to create
>> quite a nice map of the US states, colorized by state population
>> levels. See
>> http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .
>>
>> But the method I'm using for the colorization is clunky and I'm sure
>> it can be improved upon. Here's my input file:
>>
>> <gnuplot>
>> set term pngcairo size 660,400
>> set output 'statepop.png'
>> set linetype 1 lc rgb "white" lw 1
>>
>> set palette model HSV file 'statepop.hsv'
>> set cbrange [0:50]
>> unset colorbox
>>
>> set xrange [95:210]
>> set yrange [-175:-135]
>> set noxtics
>> set noytics
>> set border 0
>> unset key
>>
>> plot for [i=0:*] 'merc.dat' index i with filledcurves \
>>   fc palette cb i, 'merc.dat' with lines lt 1
>> </gnuplot>
>>
>> In the above, 'merc.dat' contains the state outlines from the .shp
>> file. The population data get into the picture via the pre-processed
>> 'statepop.hsv'. To produce this (with its shades of blue) I ran a
>> loop across the states using H = 229/360, V = 93/100, and S[i] =
>> population of state i divided by the max population value.
>>
>> Any suggestions on the best way to do the colorization within
>> gnuplot? And also, perhaps, how to discretize it (by decile for
>> instance)? Is there a way to replace
>>
>>    fc palette cb i
>>
>> with something like
>>
>>    fc palette cb <function of i and the data to be colorized>
>
> Assuming you can get the state's population from somewhere
> (maybe the header of the data block in the outlines file?)
> the palette need not be involved.

In general the data one wants to represent via color on a map will 
not be present in the outlines file; they'll come from some other 
source (as in my population data).

>   blue = 0x000044
>   white = 0xffffff
>   color(i) =  pop(i)/maxpop * blue + (maxpop-pop(i))/maxpop * white
>
> If you use your array S[], that becomes
>   color(i) = S[i] * blue + (1.0-S[i]) * white
>
> Then you can plot using the color directly
>
>   plot for [i=0:*] 'merc.dat' index i using 1:2:(color(i)) with filledcurves \
>           fc rgb variable

Nice, thanks. Using a gnuplot array for the "extra" data is clearly 
a good solution. My only problem is that I'm trying to come up with 
something that works for gnuplot >= 5.0 (and arrays are new in 5.2).

I've found one alternative to my original approach: In preparing the 
data for gnuplot, I append a third column after the coordinate pairs 
for the vertices of the outlines. The values in this column repeat 
the population (or whatever) value for each entity. So now I can do 
something like:

set cbrange [0:1]
set palette defined (0 'white', 1 'steelblue')
...
plot for [i=0:*] 'states.dat' index i with filledcurves \
  fc palette, 'states.dat' using 1:2 with lines

where a little slice of one of the states in 'states.dat' looks 
like this:

# longitude, latitude, popratio
-85.799227 41.763535 0.25275361
-86.068302 41.764628 0.25275361
-86.234565 41.764864 0.25275361
-86.525181 41.765540 0.25275361
-86.834829 41.765504 0.25275361

Allin Cottrell

Re: geographic plotting

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

On Monday, 13 April 2020 13:14:54 PDT Allin Cottrell wrote:
> On Fri, 6 Mar 2020, Ethan A Merritt wrote:
> 
> [a propos Manfred Schwarb's suggestion of using GeoJSON files
> for geographic plotting in gnuplot]
> 
> > Good call.  Geojson looks quite promising.
> > A real parser should be easy, but even a quick pass through sed
> > or a text editor makes it usable.
> > I have posted a proof-of-principle example using US state boundary
> > data from a sample file on the geojson development site:
> >
> >  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/
> 
> Thanks for the example, Ethan.
> 
> I've recently returned to this issue, exploring the shapefiles 
> option. I've written some relevant utilities in C, designed to link 
> against Frank Warmerdam's lipshape. (I'll be happy to share these 
> once they're better tested.) With their help I've managed to create 
> quite a nice map of the US states, colorized by state population 
> levels. See 
> http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .
> 
> But the method I'm using for the colorization is clunky and I'm sure 
> it can be improved upon. Here's my input file:
> 
> <gnuplot>
> set term pngcairo size 660,400
> set output 'statepop.png'
> set linetype 1 lc rgb "white" lw 1
> 
> set palette model HSV file 'statepop.hsv'
> set cbrange [0:50]
> unset colorbox
> 
> set xrange [95:210]
> set yrange [-175:-135]
> set noxtics
> set noytics
> set border 0
> unset key
> 
> plot for [i=0:*] 'merc.dat' index i with filledcurves \
>   fc palette cb i, 'merc.dat' with lines lt 1
> </gnuplot>
> 
> In the above, 'merc.dat' contains the state outlines from the .shp
> file. The population data get into the picture via the pre-processed
> 'statepop.hsv'. To produce this (with its shades of blue) I ran a
> loop across the states using H = 229/360, V = 93/100, and S[i] =
> population of state i divided by the max population value.
> 
> Any suggestions on the best way to do the colorization within 
> gnuplot? And also, perhaps, how to discretize it (by decile for 
> instance)? Is there a way to replace
> 
>    fc palette cb i
> 
> with something like
> 
>    fc palette cb <function of i and the data to be colorized>

Assuming you can get the state's population from somewhere
(maybe the header of the data block in the outlines file?)
the palette need not be involved.

   blue = 0x000044
   white = 0xffffff
   color(i) =  pop(i)/maxpop * blue + (maxpop-pop(i))/maxpop * white

If you use your array S[], that becomes
   color(i) = S[i] * blue + (1.0-S[i]) * white

Then you can plot using the color directly

   plot for [i=0:*] 'merc.dat' index i using 1:2:(color(i)) with filledcurves \
           fc rgb variable

		Ethan

> Allin Cottrell

Re: Fast image markup?

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

On Monday, 13 April 2020 11:08:01 PDT Dima Kogan wrote:

> >> I tried big images too. I THINK they work, but it's still really slow
> >> compared to any image viewer. Is that expected? Should it be faster than
> >> what "with rgbimage" does?
> >
> > "slow" when doing what?  rotating in 3D?
> > Can you do that in a normal image viewer?
> 
> Just the simplest usage: plot an image with some annotations. No 3d or
> any transformations of anything. Compared to image viewers the speed
> difference isn't subtle.

I may be misunderstanding what you are doing (quite possible).

For me using a large image (say a 1365x1024 jpg "wallpaper" photo)
as a background introduces no noticeable delay at all using the wxt
terminal.  Even for 3D rotation the response is instantaneous:

    set term wxt size 1500,1000
    set pixmap 1 at screen 0,0 size screen 1,1 behind '~/images/wallpaper/p1040193.jpg'
    splot x*y with pm3d
    [rotate/zoom/translate with mouse as normal]

For x11 the initial display is very quick, but the response to 3D rotation
is somewhat laggy.  Not bad, though.  

The strange one is actually qt, where the response to 3D rotation is horribly slow.
Zoom and pan in 2D is quick however. I'll bet there is some way to speed up the qt 
3D rendering also, but it will require some investigation. 

	Ethan

Re: geographic plotting

[Allin C. <cot...@wf...>]

On Fri, 6 Mar 2020, Ethan A Merritt wrote:

[a propos Manfred Schwarb's suggestion of using GeoJSON files
for geographic plotting in gnuplot]

> Good call.  Geojson looks quite promising.
> A real parser should be easy, but even a quick pass through sed
> or a text editor makes it usable.
> I have posted a proof-of-principle example using US state boundary
> data from a sample file on the geojson development site:
>
>  http://skuld.bmsc.washington.edu/people/merritt/gnuplot/

Thanks for the example, Ethan.

I've recently returned to this issue, exploring the shapefiles 
option. I've written some relevant utilities in C, designed to link 
against Frank Warmerdam's lipshape. (I'll be happy to share these 
once they're better tested.) With their help I've managed to create 
quite a nice map of the US states, colorized by state population 
levels. See 
http://ricardo.ecn.wfu.edu/pub/gretl/datamaps/statepop.png .

But the method I'm using for the colorization is clunky and I'm sure 
it can be improved upon. Here's my input file:

<gnuplot>
set term pngcairo size 660,400
set output 'statepop.png'
set linetype 1 lc rgb "white" lw 1

set palette model HSV file 'statepop.hsv'
set cbrange [0:50]
unset colorbox

set xrange [95:210]
set yrange [-175:-135]
set noxtics
set noytics
set border 0
unset key

plot for [i=0:*] 'merc.dat' index i with filledcurves \
  fc palette cb i, 'merc.dat' with lines lt 1
</gnuplot>

In the above, 'merc.dat' contains the state outlines from the .shp
file. The population data get into the picture via the pre-processed
'statepop.hsv'. To produce this (with its shades of blue) I ran a
loop across the states using H = 229/360, V = 93/100, and S[i] =
population of state i divided by the max population value.

Any suggestions on the best way to do the colorization within 
gnuplot? And also, perhaps, how to discretize it (by decile for 
instance)? Is there a way to replace

   fc palette cb i

with something like

   fc palette cb <function of i and the data to be colorized>

?

Allin Cottrell

Re: First release candidate for gnuplot version 5.4

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

Ethan A Merritt writes:
>> The tutorial seems missing from the 5.4 branch and tarball, but still
>> available in master.  Is that intentional?
>
> Yes.  
>
> The latex tutorial was written for the old, old latex drivers "set term latex"
> and "set term eepic" that are no longer included in the gnuplot distribution. 
> The tutorial source is still in master in case it inspires  someone to
> write a new one illustrating use of the newer terminals relevant to latex.

I would suggest to mention that in the release notes and move on, then.

I have made the RC1 available on Cygwin in both 32bit and 64bit variants
for testing.


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

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: First release candidate for gnuplot version 5.4

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

On Monday, 13 April 2020 11:45:42 PDT Achim Gratz wrote:
> Ethan A Merritt writes:
> > You can download a source tarball for the first version 5.4 release candidate from 
> >
> >     https://sf.net/projects/gnuplot/files/testing/gnuplot-5.4.rc1.tar.gz
> 
> The tutorial seems missing from the 5.4 branch and tarball, but still
> available in master.  Is that intentional?

Yes.  

The latex tutorial was written for the old, old latex drivers "set term latex"
and "set term eepic" that are no longer included in the gnuplot distribution. 
The tutorial source is still in master in case it inspires  someone to
write a new one illustrating use of the newer terminals relevant to latex.

	Ethan