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

Re: geographic plotting

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

On Wed, 4 Mar 2020, Manfred Schwarb wrote:

> > This may be putting the cart before the horse, but...
> > Do you think it would be helpful to teach gnuplot to read shape files?
> > I imagine it would be possible to test for the presence of shapelib.so
> > and provide a binary input mode:
> >
> >    splot <data> binary filetype=shapelib  with polygons
> >
> > I have never worked with this libary so I don't know if it is organized
> > in such a way that this would be possible.
>
> I do it using the gdal software and some shell magic:
>   # ogr2ogr -f "GMT" gaga.gmt gaga.shp
>   # grep -v "^#" gaga.gmt | sed 's/>//' > gaga.txt

That's also the approach taken by Bob Mesibov at
https://www.datafix.com.au/BASHing/2018-10-31.html

I'm hopeful that libshape can do the job without requiring the whole
of gdal. Libshape was developed by Frank Warmerdam, the guy who
initially developed gdal, and is used by gdal's OGR library.

Allin Cottrell

Re: geographic plotting

[Manfred S. <man...@gm...>]

>
> This may be putting the cart before the horse, but...
> Do you think it would be helpful to teach gnuplot to read shape files?
> I imagine it would be possible to test for the presence of shapelib.so
> and provide a binary input mode:
>
>    splot <data> binary filetype=shapelib  with polygons
>
> I have never worked with this libary so I don't know if it is organized
> in such a way that this would be possible.


I do it using the gdal software and some shell magic:
  # ogr2ogr -f "GMT" gaga.gmt gaga.shp
  # grep -v "^#" gaga.gmt | sed 's/>//' > gaga.txt

HTH,
Manfred


>
> A quick look at the spec for the shapefile format makes it look horrible
> (mixed little-ending big-endian in the same file?! variable record types
> that are required not to vary?!),  but if it is hidden by a usable library ....
>
> 	Ethan
>
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: geographic plotting

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

On Tue, 3 Mar 2020, Ethan A Merritt wrote:

> On Tuesday, 3 March 2020 17:05:40 PST Allin Cottrell wrote:
>> On Tue, 3 Mar 2020, Ethan A Merritt wrote:
>>
>>> On Tuesday, 3 March 2020 14:30:40 PST Allin Cottrell wrote:
>>>> This question has been posed before (a few years back) but I'm
>>>> hoping someone may be able to point me to the state-of-the-art,
>>>> if there is such.
>>>>
>>>> I'd like to be able to produce via gnuplot a map of (for example)
>>>> the USA showing the states colored by median income, or PM2.5
>>>> particulate emissions, or whatever.
>>>>
>>>> I understand that the starting point would be a suitable US states
>>>> shapefile (I know where I can get that), which would have to be
>>>> translated to a format (resembling world.dat, I suppose) that can be
>>>> understood by gnuplot. I have some notion of how that might be done.
>>>>
>>>> The next issue would be to get gnuplot to colorize specified areas
>>>> of the map according to the values of some additional data.
>>>> Unfortunately I have little notion of how to do that.
>>>
>>> The development version of gnuplot supports
>>>
>>> 	splot <data> with polygons
>>
>> Thanks Ethan, and also Dima in this thread. This sounds promising!
>> Right now I'm not sure when I'll find time to pursue this in depth,
>> but I'm definitely interested and will push it when I can.
>>
>> Allin Cottrell
>
> This may be putting the cart before the horse, but...
> Do you think it would be helpful to teach gnuplot to read shape files?

I'm sure it would be helpful...

> I imagine it would be possible to test for the presence of shapelib.so
> and provide a binary input mode:
>
>   splot <data> binary filetype=shapelib  with polygons
>
> I have never worked with this libary so I don't know if it is organized
> in such a way that this would be possible.

but I'm not yet clear on that point myself. I've taken a quick look 
at shapelib-1.5.0 (which configures and compiles without fuss on my 
machine) and seen that it can convert both .shp and .dbf files to 
what look like comprehensible text formats that "ought to be" 
usable (shp -> polygons that could go into CSV quite easily, and dbf 
-> descriptions of the elements of the shp file in their order of
appearance).

But when I said I "had some notion" of how shapelib could help, that 
wasn't an understatement! Perhaps better to say I "had an inkling" 
of how it could help.

I aim to follow up, but I'll be offline next week so I won't get 
back to this till the week after.

Allin

Re: geographic plotting

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

On Tuesday, 3 March 2020 17:05:40 PST Allin Cottrell wrote:
> On Tue, 3 Mar 2020, Ethan A Merritt wrote:
> 
> > On Tuesday, 3 March 2020 14:30:40 PST Allin Cottrell wrote:
> >> This question has been posed before (a few years back) but I'm
> >> hoping someone may be able to point me to the state-of-the-art,
> >> if there is such.
> >>
> >> I'd like to be able to produce via gnuplot a map of (for example)
> >> the USA showing the states colored by median income, or PM2.5
> >> particulate emissions, or whatever.
> >>
> >> I understand that the starting point would be a suitable US states
> >> shapefile (I know where I can get that), which would have to be
> >> translated to a format (resembling world.dat, I suppose) that can be
> >> understood by gnuplot. I have some notion of how that might be done.
> >>
> >> The next issue would be to get gnuplot to colorize specified areas
> >> of the map according to the values of some additional data.
> >> Unfortunately I have little notion of how to do that.
> >
> > The development version of gnuplot supports
> >
> > 	splot <data> with polygons
> 
> Thanks Ethan, and also Dima in this thread. This sounds promising!
> Right now I'm not sure when I'll find time to pursue this in depth, 
> but I'm definitely interested and will push it when I can.
> 
> Allin Cottrell

This may be putting the cart before the horse, but...
Do you think it would be helpful to teach gnuplot to read shape files?
I imagine it would be possible to test for the presence of shapelib.so
and provide a binary input mode:

   splot <data> binary filetype=shapelib  with polygons

I have never worked with this libary so I don't know if it is organized
in such a way that this would be possible.

A quick look at the spec for the shapefile format makes it look horrible
(mixed little-ending big-endian in the same file?! variable record types
that are required not to vary?!),  but if it is hidden by a usable library ....

	Ethan
	

Re: geographic plotting

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

On Tue, 3 Mar 2020, Ethan A Merritt wrote:

> On Tuesday, 3 March 2020 14:30:40 PST Allin Cottrell wrote:
>> This question has been posed before (a few years back) but I'm
>> hoping someone may be able to point me to the state-of-the-art,
>> if there is such.
>>
>> I'd like to be able to produce via gnuplot a map of (for example)
>> the USA showing the states colored by median income, or PM2.5
>> particulate emissions, or whatever.
>>
>> I understand that the starting point would be a suitable US states
>> shapefile (I know where I can get that), which would have to be
>> translated to a format (resembling world.dat, I suppose) that can be
>> understood by gnuplot. I have some notion of how that might be done.
>>
>> The next issue would be to get gnuplot to colorize specified areas
>> of the map according to the values of some additional data.
>> Unfortunately I have little notion of how to do that.
>
> The development version of gnuplot supports
>
> 	splot <data> with polygons

Thanks Ethan, and also Dima in this thread. This sounds promising!
Right now I'm not sure when I'll find time to pursue this in depth, 
but I'm definitely interested and will push it when I can.

Allin Cottrell

Re: geographic plotting

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

On Tuesday, 3 March 2020 15:47:32 PST Dima Kogan wrote:
> Ethan: do you have any data and sample scripts that plot real-world
> geographic polygons? If it's now a pain, I'd like to try it out.

I wish I did, for demo purposes if nothing else.
My time is spent in the atomic coordinate space of molecular modeling,
not the latitude/longitude space of earthly geography.
If Allin puts together a space-description file I'd be happy to
work up some demo scripts that use it.

	Ethan

Re: geographic plotting

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

Ethan: do you have any data and sample scripts that plot real-world
geographic polygons? If it's now a pain, I'd like to try it out.

Re: geographic plotting

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

On Tuesday, 3 March 2020 14:30:40 PST Allin Cottrell wrote:
> This question has been posed before (a few years back) but I'm 
> hoping someone may be able to point me to the state-of-the-art,
> if there is such.
> 
> I'd like to be able to produce via gnuplot a map of (for example) 
> the USA showing the states colored by median income, or PM2.5 
> particulate emissions, or whatever.
> 
> I understand that the starting point would be a suitable US states 
> shapefile (I know where I can get that), which would have to be 
> translated to a format (resembling world.dat, I suppose) that can be 
> understood by gnuplot. I have some notion of how that might be done.
> 
> The next issue would be to get gnuplot to colorize specified areas 
> of the map according to the values of some additional data. 
> Unfortunately I have little notion of how to do that.

The development version of gnuplot supports 

	splot <data> with polygons

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
gnuplot> help polygons

      splot DATA {using x:y:z} with polygons
            {fillstyle <fillstyle spec>}
            {fillcolor <colorspec>}
 `splot with polygons` uses pm3d to render individual triangles, quadrangles,
 and larger polygons in 3D.  These may be facets of a 3D surface or isolated
 shapes. The code assumes that the vertices lie in a plane.
 Vertices defining individual polygons are read from successive records of the
 input file.  A blank line separates one polygon from the next.

 The fill style and color may be specified in the splot command, otherwise the
 global fillstyle from `set style fill` is used.  Due to limitations in the
 pm3d code, a single border line style from `set pm3d border` is applied to all
 polygons.  This restriction may be removed in a later gnuplot version.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

This plot mode will be in version 5.4 (release candidate coming soonish).
Meanwhile you can build from the source for either branch:
  master
  branch-5-4-stable

I realize you don't need 3D, but plotting in projection is easy, and you even
have the option to map it onto a globe :-) 

I am uncertain whether there is adequate flexibility to use the 3rd coordinate
as a color flag.  If there isn't, there probably should be so let me know and 
I'll work on it.    

	Ethan

Re: geographic plotting

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

This MAY answer your question. I've done this sort of visualization
before by grabbing raster map images from any tile server (openstreetmap
for instance), and plotting data on top of the image.

Script to

- download the tiles you want
- stitch them together into one image you will be overlaying
- generate a template gnuplot script to plot this image

is available here:

  https://github.com/dkogan/osmgnuplot

The script plots lat/lon on one set of axes, and image pixel coords on
the other set. The mapping isn't linear, and the generated script
handles this. So you can plot your overlay with latlon coords. Works
great. Some (very simple) results in these blog posts:

  http://notes.secretsauce.net/notes/2017/09/25_pole-of-road-inaccessibility-of-the-contiguous-us.html

  http://notes.secretsauce.net/notes/2015/08/16_least-convenient-location-in-los-angeles-from-koreatown.html

geographic plotting

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

This question has been posed before (a few years back) but I'm 
hoping someone may be able to point me to the state-of-the-art,
if there is such.

I'd like to be able to produce via gnuplot a map of (for example) 
the USA showing the states colored by median income, or PM2.5 
particulate emissions, or whatever.

I understand that the starting point would be a suitable US states 
shapefile (I know where I can get that), which would have to be 
translated to a format (resembling world.dat, I suppose) that can be 
understood by gnuplot. I have some notion of how that might be done.

The next issue would be to get gnuplot to colorize specified areas 
of the map according to the values of some additional data. 
Unfortunately I have little notion of how to do that.

Please don't point me to R. I know this sort of thing can be done 
via R packages -- with the help of hundreds of megabytes of 
additional GIS software! But it seems to me it should be doable much 
more simply, perhaps using the shapelib library (a few hundred 
Kbytes in size), if I could just figure out how to do a heatmap-type 
thing but filling irregular polygons rather than just rectangles.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

libcerf function voigt_hwhm not suitable for external use

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

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

Re: Inconsistent point types between terminals

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

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

Re: Inconsistent point types between terminals

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

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?

Re: Inconsistent point types between terminals

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

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

Re: Support XDG base directory for gnuplotrc

[Henri M. <hen...@gm...>]

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

Inconsistent point types between terminals

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

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

Re: Support XDG base directory for gnuplotrc

[Henri M. <hen...@gm...>]

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

Re: Support XDG base directory for gnuplotrc

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

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

Support XDG base directory for gnuplotrc

[Henri M. <hen...@gm...>]

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

Re: Odd behavior of "set border" and "splot"

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

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!

Re: Odd behavior of "set border" and "splot"

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

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

Re: Odd behavior of "set border" and "splot"

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

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!

Re: Odd behavior of "set border" and "splot"

[Ethan M. <eam...@gm...>]

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

Re: Odd behavior of "set border" and "splot"

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

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

Re: Odd behavior of "set border" and "splot"

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

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.