Quantcast

Plans for gnuplot version 5

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Plans for gnuplot version 5

sfeam
This is a reminder that a first release candidate for gnuplot version 5
is planned for later this year. In preparation for that I will bump the
version information in the current development source tree to 5.0.alpha.

The rationale for calling the next release 5.0 rather than 4.8 is that it
will break or at least bend the strong backwards compatibility promised for
successive gnuplot releases within version 4. The incompatible changes,
although not major, mean that some old gnuplot command scripts will not
run without revision. A short list of the incompatible changes is below.
The many entirely new features in version 5 are not in this list because
they do not affect execution of old scripts.

Important note:  If there is some behaviour or syntax in gnuplot
that has been annoying you for the last 20 years, please speak up.
This is the best chance you will have to get it changed!

Changes already in CVS that can affect the behaviour of old scripts:

 * `set axis [*:*] reverse` autoscales with inverted axis range as before
   but the "reverse" keyword has no effect when [min:max] is explicit.

 * The interpretation of what each column of input means is no longer done
   separately for each line; whatever interpretation is used for the first
   line will be applied to the rest of the data. See examples under
   `help missing` in the current documentation.

 * NaN in an input data file is treated as a "missing" data point rather
   than a "bad" data point. This was already true for structured data
   (e.g. 3D grids) but is a change for generic 2D data.

 * The epoch boundary in time formats is now 1-Jan-1970, matching the rest
   of the unix world, rather than 1-Jan-2000.

 * Fit now handles more than 5 independent variables and accepts associated
   error values. The names of the fit variables other than the first two
   (x, y) are now dissociated from the axis definitions.  
   E.g. set urange [foo:baz] has no effect on fitting.
   You can define them using `set dummy x, y, var3, var4, ...`

 * Enhanced text mode is now the default.
   It is used by the new default tic format "%h".

 * The old syntax for passing parameters to a `call` statement was out of
   date. For example it did not distinguish between quoted and unquoted
   strings or variables. It has been replaced by a new syntax using string
   variables ARG0, ARG1, ... that behaves similarly to arguments passed by
   a unix shell script.  See the callargs.dem demo.

 * Labeled contours are now a separate plot style. The command controlling
   contour labels has also changed.  See `help set cntrlabel`.

I know of two proposed incompatible changes that are not yet implemented.
Please speak up if you have an opinion for or against these.

 * The high byte of RGB color values is now interpreted as an alpha value.
   I.e.  0xRRGGBB (== 0x00RRGGBB) is some solid RGB color; 0x55RRGGBB is a
   semi-transparent variant of that same color. This only works if 0x00 in
   the high byte is interpreted as "solid". Unfortunately, the current
   interpretation of RGBA image data uses the opposite convention:
   alpha=0 is fully transparent, while alpha=0xFF is solid color.

   Should we change the interpretation of the alpha channel in RGBA image
   data to match that of lines and fill areas?

 * Binary and ascii matrices now support mostly the same set of formats,
   but the syntax used to describe them in inconsistent.
   The current documentation explains this in detail under `help matrix`.

   What should version 5 do?
   Change the binary matrix options to match those of ascii matrices?
   Change the ascii matrix options to match those of binary matrices?
   Change both to some new convention?
   Leave them as they are?

                        Ethan

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Plotter-2
On 03/05/14 05:51, sfeam wrote:
>   * `set axis [*:*] reverse` autoscales with inverted axis range as before
>     but the "reverse" keyword has no effect when [min:max] is explicit.

Last year I found some oddity with regards to reversal.

I can't remember enough detail to give a reproducible example but my
recollection was that once it was given set axis with max<min it latched
into a reverse state and subsequent set axis with max>min failed to
revert to non-reversed axis orientation.

Peter.


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Liu Guibin
In reply to this post by sfeam
I expect that gnuplot can have the following several functions:

<1>.

I expect that the keys (legends) can be manipulated in groups in stead
of as a whole objects.

e.g.

set key 1 top right
set key 2 bottom left
plot 'data' t 't1a' key 1, '' t 't1b' key 1, '' t 't2a' key 2, '' t
't2b' key 2

Thus, if I have many legends and there's no space to put them together,
I can divide them into two groups
"key 1" and "key 2" and put them at different places.


<2>.

Columns from different files can be calculated together. e.g. I have two
files that have the same format, say, 100 row of (x, y) data, named
'file1' and 'file2'. Now I want to plot the different between y columns
from the two files.

plot 'file1' u 1:($2-column('file2',2)) w lp


<3>.

I expect gnuplot to have arrays.


<4>.

I want to set the style of dashed line, that is, how dashed the line is.
e.g. - - - - or - - - - or -- -- -- ....



gbliu


于 2014-03-05 12:51, sfeam 写道:
> Important note:  If there is some behaviour or syntax in gnuplot
> that has been annoying you for the last 20 years, please speak up.
> This is the best chance you will have to get it changed!


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Jon Gjengset
In reply to this post by sfeam
> Important note:  If there is some behaviour or syntax in gnuplot
> that has been annoying you for the last 20 years, please speak up.
> This is the best chance you will have to get it changed!

Well, I have always been frustrated with how margins and xy-labels work
for multiplots. For example, say you want a five-plot wide multiplot,
and you want a y-label only for the first, and an x-label in the middle.
If you simply use "set ylabel"/"set xlabel" for the first and center
plots respectively, this will squish those two plots relative to the
others. Labels can be added manually using "set label", but this isn't
quite as easy a solution. Margins have a similar problem - if you set a
left margin on the leftmost plot, the graph itself will become narrower
than the other graphs.

One way of overcoming this might be to add the ability to set x/y labels
and margins for the multiplot itself by setting them before "set layout
multiplot", but this will break backwards-compatability.

Another item that is high on my wishlist is to make multiplotting
multithreaded (one plotter per plot). While this may not matter much for
a 4,1 plot, it does for a 14,25 and for "set term gif animate" with 90k
plots. It might break some scripts that rely on sequential plotting
(imagine two plots that use a function which reads/modifies a
global variable).

Finally, native support for dynamic plots would be great. There are
hacks you can do such as [this][1], but having it built-in would be a
killer feature. This might not affect backwards compatability, but I
thought I'd mention it while I'm at it anyway.

> I know of two proposed incompatible changes that are not yet implemented.
> Please speak up if you have an opinion for or against these.
>
>  * The high byte of RGB color values is now interpreted as an alpha value.

It seems to me that standardizing on something people might be familiar
with is the way to go here. In most implementations I am familiar with,
ARGB colors have a higher alpha mean more "solid", matching the current
gnuplot form. I think we should stick to that and explicitly handle RGB
to ARGB conversion by setting A=0xFF.

>  * Binary and ascii matrices now support mostly the same set of formats,

While I have little experience with using the binary format, I feel one
missing part of the matrix format has always been the ability to plot
each pixel individually (give x,y,z explicitly for each row) rather than
to require a certain organization of rows/columns. Thoughts on this? It
might not be relevant for this discussion though...

  [1]: http://techthat.net/2014/01/29/incremental-plotting-in-gnuplot/

Jon

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Plotter-2
On Wednesday, 05 March, 2014 08:22:25 [hidden email] wrote:

> On 03/05/14 05:51, sfeam wrote:
> >   * `set axis [*:*] reverse` autoscales with inverted axis range as before
> >     but the "reverse" keyword has no effect when [min:max] is explicit.
>
> Last year I found some oddity with regards to reversal.
>
> I can't remember enough detail to give a reproducible example but my
> recollection was that once it was given set axis with max<min it latched
> into a reverse state and subsequent set axis with max>min failed to
> revert to non-reversed axis orientation.

Yes.  That was a long-standing problem that the new syntax fixes.
See for example
  https://sourceforge.net/p/gnuplot/bugs/317/
 
As with the other changes listed, there is a good reason for the change.
But it unfortunately has the side effect some old scripts may no longer
work as intended.



------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Liu Guibin
On Wednesday, 05 March, 2014 19:18:24 Liu Guibin wrote:
> I expect that gnuplot can have the following several functions:
[multiple keys]
[multiple files in the same using spec]
[arrays]
[control over dashed lines]

In general adding a new feature does not break older scripts or familiar usage.
So in general a new feature can be added at any time; it does not need to
wait for a transition from one major release to the next, in this case version 4
to version 5.

The four features you mention are reasonable suggestions.
That does not mean that it would be easy to implement, but if someone
someone contributes code for any or all of them I don't see any
obvious reason why they couldn't be added  when ready without breaking
backward compatibility.

Two of these, more control over key placement and multiple files contributing
to a single plot, are already tracked in the Feature Requests section on
the project development site on SourceForge.  The other two, arrays and
dashed lines, have been discussed on the mailing list but I do not see
Feature Request entries for them.  Feel free to add them.

        Ethan




>
> <1>.
>
> I expect that the keys (legends) can be manipulated in groups in stead
> of as a whole objects.
>
> e.g.
>
> set key 1 top right
> set key 2 bottom left
> plot 'data' t 't1a' key 1, '' t 't1b' key 1, '' t 't2a' key 2, '' t
> 't2b' key 2
>
> Thus, if I have many legends and there's no space to put them together,
> I can divide them into two groups
> "key 1" and "key 2" and put them at different places.
>
>
> <2>.
>
> Columns from different files can be calculated together. e.g. I have two
> files that have the same format, say, 100 row of (x, y) data, named
> 'file1' and 'file2'. Now I want to plot the different between y columns
> from the two files.
>
> plot 'file1' u 1:($2-column('file2',2)) w lp
>
>
> <3>.
>
> I expect gnuplot to have arrays.
>
>
> <4>.
>
> I want to set the style of dashed line, that is, how dashed the line is.
> e.g. - - - - or - - - - or -- -- -- ....
>
>
>
> gbliu
>
>
> 于 2014-03-05 12:51, sfeam 写道:
> > Important note:  If there is some behaviour or syntax in gnuplot
> > that has been annoying you for the last 20 years, please speak up.
> > This is the best chance you will have to get it changed!
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> [hidden email]
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Jon Gjengset
On Wednesday, 05 March, 2014 12:37:47 Jon Gjengset wrote:

> > Important note:  If there is some behaviour or syntax in gnuplot
> > that has been annoying you for the last 20 years, please speak up.
> > This is the best chance you will have to get it changed!
>
> Well, I have always been frustrated with how margins and xy-labels work
> for multiplots. For example, say you want a five-plot wide multiplot,
> and you want a y-label only for the first, and an x-label in the middle.
> If you simply use "set ylabel"/"set xlabel" for the first and center
> plots respectively, this will squish those two plots relative to the
> others. Labels can be added manually using "set label", but this isn't
> quite as easy a solution. Margins have a similar problem - if you set a
> left margin on the leftmost plot, the graph itself will become narrower
> than the other graphs.

Have you looked at the proposed patch
"Multiplot auto layout with explicit margins and spacing"?

    https://sourceforge.net/p/gnuplot/patches/611/

Your feedback or testing would be valuable, and I think the patch could
be added to the code base either before or after the next release if
people want it.

> Another item that is high on my wishlist is to make multiplotting
> multithreaded (one plotter per plot). While this may not matter much for
> a 4,1 plot, it does for a 14,25 and for "set term gif animate" with 90k
> plots. It might break some scripts that rely on sequential plotting
> (imagine two plots that use a function which reads/modifies a
> global variable).

I am not sure I understand what you are asking for there.
Many terminals allow you to embed the gnuplot output into a
larger window or document.  You can use this to tile many plots,
each created or managed by a separate gnuplot instance, rather
than creating a single multiplot.  
Is that what you have in mind?
 
> Finally, native support for dynamic plots would be great. There are
> hacks you can do such as [this][1], but having it built-in would be a
> killer feature. This might not affect backwards compatability, but I
> thought I'd mention it while I'm at it anyway.

I have a patchset that implements this.
I can dust it off and put it up on SourceForge for you to test if you like.
In actual testing I was very disappointed with it, so I didn't pursue it.
Maybe your potential application is sufficiently different from mine
that it would make more of a difference, or maybe you can suggest
a better approach.
 

> > I know of two proposed incompatible changes that are not yet implemented.
> > Please speak up if you have an opinion for or against these.
> >
> >  * The high byte of RGB color values is now interpreted as an alpha value.
>
> It seems to me that standardizing on something people might be familiar
> with is the way to go here. In most implementations I am familiar with,
> ARGB colors have a higher alpha mean more "solid", matching the current
> gnuplot form. I think we should stick to that and explicitly handle RGB
> to ARGB conversion by setting A=0xFF.

Please expand on this suggestion.

Currently (version 4) you can plot with RGB colors by saying, for instance
   plot  ... using 1:2:3 linecolor rgb variable
where input column 3 contains 24-bit RGB values.
Bits 25-32 are ignored, and the lines are all solid color.

In the development version (planned version 5) this same command will
treat the high bits as an alpha channel. If the bits are non-zero
then you will get lines of varying translucency.   See the demo
   http://gnuplot.sourceforge.net/demo_cvs/rgba_lines.html
If the high bits are zero, then you get the same output as in version 4
(solid lines).  This backwards compatibility would break if 0 is interpreted
as transparent rather than solid.

Are you suggesting that any command using the keyword "rgb" should
ignore the high bits?
I.e. that a new keyword rgba or argb should be introduced everywhere?
And than what - the program would invert the high byte during input?  

[Just as an aside...  I have worked with RGB + Alpha in many programs for
many years, and in my experience the internal representation in different file
formats and programs is all over the map.  So I am less than convinced that
everyone would have the same expectation.  I'm more concerned that it is
confusing to have gnuplot itself use two different conventions]


> >  * Binary and ascii matrices now support mostly the same set of formats,
>
> While I have little experience with using the binary format, I feel one
> missing part of the matrix format has always been the ability to plot
> each pixel individually (give x,y,z explicitly for each row) rather than
> to require a certain organization of rows/columns. Thoughts on this? It
> might not be relevant for this discussion though...

That is currently (version 4.7) supported as
    plot ... binary nonuniform matrix

It is an example of the inconsistency of the ascii and binary keywords,
since the binary case needs an extra keyword to specifiy what is
already the default in the ascii case.

        Ethan

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Jon Gjengset
> Have you looked at the proposed patch
> "Multiplot auto layout with explicit margins and spacing"?
>
>     https://sourceforge.net/p/gnuplot/patches/611/
>
> Your feedback or testing would be valuable, and I think the patch could
> be added to the code base either before or after the next release if
> people want it.

Ah, no, I had not seen that. Will have a look once I have the time!

> > Another item that is high on my wishlist is to make multiplotting
> > multithreaded.
>
> I am not sure I understand what you are asking for there.
> Many terminals allow you to embed the gnuplot output into a
> larger window or document.  You can use this to tile many plots,
> each created or managed by a separate gnuplot instance, rather
> than creating a single multiplot.  
> Is that what you have in mind?

Not quite.
For example, I have a plotting script that plots ~90k datasets using the
animated gif terminal. That is, I call "plot" 90k times in a single
gnuplot session, and each one becomes a frame in the resulting animated
gif. However, at the moment, these datasets are plotted sequentially,
and so although I have a 24-core machine, only one core is doing the
plotting. Ideally, each core would be responsible for some subset of the
plots, and then they would all be merged at the end.

The same applies to creating a multiplot containing hundreds of plots;
at the moment they are plotted one after the other, whereas they could
theoretically be plotted in parallel. I am not familiar with the tiled,
embedded plotting you mention, but although it might solve this latter
problem, it certainly won't solve the former.

> > Finally, native support for dynamic plots would be great.
>
> I have a patchset that implements this.
> I can dust it off and put it up on SourceForge for you to test if you like.

That would be great!
I'm working toward a deadline this week, but will hopefully be able to
take a look next week.

> In actual testing I was very disappointed with it, so I didn't pursue it.

How come?

> > >  * The high byte of RGB color values is now interpreted as an alpha value.
> >
> > It seems to me that standardizing on something people might be familiar
> > with is the way to go here.
>
> Please expand on this suggestion.
>
> Currently (version 4) you can plot with RGB colors by saying, for instance
>    plot  ... using 1:2:3 linecolor rgb variable
> where input column 3 contains 24-bit RGB values.
> Bits 25-32 are ignored, and the lines are all solid color.

Ah, I see, I was thinking of literal RGB values (#AARRGGBB), not their
binary representation. Hence also my reference to what seems to be
"common".

> Are you suggesting that any command using the keyword "rgb" should
> ignore the high bits?
> I.e. that a new keyword rgba or argb should be introduced everywhere?
> And than what - the program would invert the high byte during input?

Yes, that seems like a sensible approach to me. Particularly so because
it will never surprise a user who is expecting RGB, but suddenly gets
RGBA. In fact, even if you don't invert the high bytes, I think the
choice to use an alpha channel should be explicit.

> > >  * Binary and ascii matrices now support mostly the same set of formats,
> >
> > While I have little experience with using the binary format, I feel one
> > missing part of the matrix format has always been the ability to plot
> > each pixel individually (give x,y,z explicitly for each row) rather than
> > to require a certain organization of rows/columns. Thoughts on this? It
> > might not be relevant for this discussion though...
>
> That is currently (version 4.7) supported as
>     plot ... binary nonuniform matrix

No, that's not quite what I meant.
I would like to have a format that lets me specify x and y explicitly in
each row along with the data. This would be particularly useful if it
also allowed data to be given out-of-order (that is, without necesarily
giving it column-wise or row-wise). I suppose that is only really
applicable to the ascii format though.

> It is an example of the inconsistency of the ascii and binary keywords,
> since the binary case needs an extra keyword to specifiy what is
> already the default in the ascii case.

I think these kinds of inconsistencies, while occasionally annoying, are
not worth breaking backwards compatability for alone. That said, now
that the decision has been made to break it anyway, sorting them out is
a good idea. Personally, I think the default matrix format (ascii or
binary) should be something like the aforementioned with explicity x and
y as that more closely matches the way input data is given to gnuplot
for 2D datasets. I think the most important thing is have the same
keywords and defaults for both formats though, whatever that format ends
up being.

Jon

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Bastian Märkisch
Am 05.03.2014 20:12, schrieb Jon Gjengset:

>> Have you looked at the proposed patch
>> "Multiplot auto layout with explicit margins and spacing"?
>>
>>      https://sourceforge.net/p/gnuplot/patches/611/
>>
>> Your feedback or testing would be valuable, and I think the patch could
>> be added to the code base either before or after the next release if
>> people want it.
>
> Ah, no, I had not seen that. Will have a look once I have the time!
>

FWIW, I have an up to date version of this patch which applies to
current CVS. I'll upload it to the tracker when I find the time.

   Bastian


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Juhász Péter
In reply to this post by sfeam
On Wed, 2014-03-05 at 09:52 -0800, Ethan A Merritt wrote:
> On Wednesday, 05 March, 2014 19:18:24 Liu Guibin wrote:
> > I expect that gnuplot can have the following several functions:
> [multiple keys]
> [multiple files in the same using spec]
> [arrays]
> [control over dashed lines]

I think that it would be best to restrict this discussion to actual
incompatible changes and not let it bloom into a full-blown
wishlist-fest.

However, given this prompt and the mention of dashed lines:

> > > Important note:  If there is some behaviour or syntax in gnuplot
> > > that has been annoying you for the last 20 years, please speak up.
> > > This is the best chance you will have to get it changed!

I cannot help but mention that I've always found the definition,
interaction and documentation of linetypes and linestyles confusing and
somewhat redundant.

In my opinion, "linetype" should mean the line pattern (continuous vs.
dashed vs. dotted vs...) and only that, while linestyle should encompass
all attributes that a line can have (color, pattern, pointinterval
etc.).
The two should be decoupled and clearly differentiated.
Linetype (meaning pattern, as defined above) should be settable
independently, on its own.

This is the main thing, while user-definable, custom linetypes (possibly
even with fancy syntax like "---..") would be a nice plus.

I might try to implement this when I have the time, provided that you
agree.

Also, may ask what is your proposed timeline for 5.0?


Peter Juhasz




------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: Plans for gnuplot version 5

Karl-Friedrich Ratzsch
In reply to this post by sfeam


On 05.03.2014 18:52, Ethan A Merritt wrote:
> On Wednesday, 05 March, 2014 19:18:24 Liu Guibin wrote:
>> I expect that gnuplot can have the following several functions:

> [arrays]

(An old favourite on my wishlist, especially for plotting several
datasets with individual fits in one plot. But, as said, not
critical for 5.0)

> [control over dashed lines]

The dashed lines and the point symbols available are different
between terminals, with postscript having the largest variety
available. As this would change the output of existing plots,
change to a common set should be done at a major release.

Afterwards the asked feature, to individually define new dash
patterns, would be easier to implement. With the current code, every
terminal needed it´s own implementation, i think.


Another thing that should be haromized between terminals is the font
selection. As this would likely break some old plots, it´s probably
also one for 5.0. (feature request 363)


  Karl

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: Plans for gnuplot version 5

Mojca Miklavec
On Wed, Mar 5, 2014 at 10:56 PM, Karl-Friedrich Ratzsch wrote:
>
>> [control over dashed lines]
>
> The dashed lines and the point symbols available are different
> between terminals, with postscript having the largest variety
> available. As this would change the output of existing plots,
> change to a common set should be done at a major release.

+1.

I understand that black-and-while plotters, ascii terminals,
black-and-green monitors etc. need(ed) different handling of
linestyles and might have only been capable of providing a limited
number of colors.

Nowadays I don't see any reason why each terminal should have its own
set of default colours, dash patterns and point types.

I know it would be a huge change, but ideally every terminal could
provide the same symbols for points, the same default colours, the
same dash patterns, (the same size [ratio], the same font size, the
same default line width ... where applicable). I see no reason why wxt
starts at different size than Qt. Or why LaTeX generates different
size of plots than TikZ. Or why the ratios and line widths of PDF and
PostScript plots would be different.

Mojca

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Juhász Péter
On Wednesday, 05 March, 2014 22:37:23 Juhász Péter wrote:
> On Wed, 2014-03-05 at 09:52 -0800, Ethan A Merritt wrote:

> I cannot help but mention that I've always found the definition,
> interaction and documentation of linetypes and linestyles confusing and
> somewhat redundant.
>
> In my opinion, "linetype" should mean the line pattern (continuous vs.
> dashed vs. dotted vs...) and only that, while linestyle should encompass
> all attributes that a line can have (color, pattern, pointinterval
> etc.).
> The two should be decoupled and clearly differentiated.
> Linetype (meaning pattern, as defined above) should be settable
> independently, on its own.

 Allowing a bit of non-backwards compatibility is one thing.
Breaking every gnuplot script in existence is quite another!

If "lt N" and "lt N+1" no longer produce distinguishable lines
then I think no one will use gnuplot any more.  The use of dot/dash
patterns to distinguish lines is only realistic for high resolution
(mostly print) devices.   So no, I do not think we can even consider
abandoning the idea that a linetype encompasses more than the
dot/dash pattern.

> This is the main thing, while user-definable, custom linetypes (possibly
> even with fancy syntax like "---..") would be a nice plus.
>
> I might try to implement this when I have the time, provided that you
> agree.

I think it would be great to introduce a new fundamental property,
"dashtype | dt" I suppose, that is shared by all capable terminals
and ignored by non-capable terminals.   I think it would be a lot of
work but I don't immediately see that it would break compatibility.

> Also, may ask what is your proposed timeline for 5.0?

That's what I'm trying to determine.

If there are no more incompatible changes to make, then so far as
I am concerned a snapshot of the current development tree can become
a 5.0.rc1 snapshot as soon as the version information is changed.
But if there are to be additional major changes to the syntax,
they should be implemented and tested first internally before
releasing an rc1 snapshot for external testing.

        Ethan


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Karl-Friedrich Ratzsch
On Wednesday, 05 March, 2014 22:56:35 Karl-Friedrich Ratzsch wrote:

>
> On 05.03.2014 18:52, Ethan A Merritt wrote:
> > On Wednesday, 05 March, 2014 19:18:24 Liu Guibin wrote:
> >> I expect that gnuplot can have the following several functions:
>
> > [control over dashed lines]
>
> The dashed lines and the point symbols available are different
> between terminals, with postscript having the largest variety
> available. As this would change the output of existing plots,
> change to a common set should be done at a major release.

[point symbols]

Could you make that proposal more specific?

Back in 2008 during the run-up to release of version 4.4 various
people put in a lot of work to make at least the first 8 point types
common across all terminals.  

Are you saying that 8 is not enough?  
That some terminals introduced since 2008 do not conform?

Either way it would help to have a specific proposal for how
many and which symbols will be in the shared set.
If there is a specific target, then I agree it would be reasonable
to include that as a release criterion.

> Afterwards the asked feature, to individually define new dash
> patterns, would be easier to implement. With the current code, every
> terminal needed it´s own implementation, i think.

[dashed lines]

Every terminal will need it's own implementation anyhow.
The underlying graphics libraries are different from each other.

Peter Juhasz (see parallel thread) is pushing for a well defined
set of dot-dash properties under user control.   I view that as an
entirely new capability, and therefore something that can be added
at any time without issues of backward compatibility.
So I'm all in favor of setting that as a goal and discussing how it is
best accomplished, but I don't think we need to hold off on version 5
while doing so.

> Another thing that should be haromized between terminals is the font
> selection. As this would likely break some old plots, it´s probably
> also one for 5.0. (feature request 363)

It is definitely not possible to offer the same font handling for all
terminals.  It is not even possible to have a single terminal,
e.g. libgd+png,  provide the same font handling across different
operating systems and library versions.

As to Feature Request 363, I agree that it would be nice to clean
up support for requesting bold/italic/etc.    Since there is no
consistency in how to capture this in a font name, I suggest that
a better approach is to extend the exhanced text mode to include
LaTeX-like markup   {\it{italic text}  and \bf{boldface text}}
Once the enhanced text code can handle the new tags,
the underlying matchup to suitable fonts can be added one
terminal type at a time.  

I'm not sure whether this should hold up version 5, even
assuming someone is keen to work on it.

        Ethan


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
In reply to this post by Mojca Miklavec
On Wednesday, 05 March, 2014 23:37:34 Mojca Miklavec wrote:
>
> I understand that black-and-while plotters, ascii terminals,
> black-and-green monitors etc. need(ed) different handling of
> linestyles and might have only been capable of providing a limited
> number of colors.
>
> Nowadays I don't see any reason why each terminal should have its own
> set of default colours, dash patterns and point types.

Already in version 4.6 you can set a default set of colours and
point types that is used by all capable terminals.
I highly recommend it, particularly because the built-in default
of red/green/blue is so awful for any number of reasons.

But yes, I suppose we could provide one or more built-in
color sets.  There are already 3 sets in the distribution package.
We could add a command:
   set colors {default|monochrome|something else}

That doesn't break compatibility however. It's just a new command.

We don't yet have control over dash patterns, but assuming that
gets added then the existing "set linetype" command will be able
to use it.  

So I think this goal has already been achieved.


        Ethan

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Karl-Friedrich Ratzsch
In reply to this post by sfeam


On 06.03.2014 00:45, Ethan A Merritt wrote:

> [point symbols]
>
> Could you make that proposal more specific?
>
> Back in 2008 during the run-up to release of version 4.4 various
> people put in a lot of work to make at least the first 8 point types
> common across all terminals.  
>
> Are you saying that 8 is not enough?  
> That some terminals introduced since 2008 do not conform?
>
> Either way it would help to have a specific proposal for how
> many and which symbols will be in the shared set.
> If there is a specific target, then I agree it would be reasonable
> to include that as a release criterion.
The first eight seem to be identical across terminals, no problem.
But windows has 15, cairo* 13, postscript 74 (!). (Origin 8.6 even
includes 117. OK, a few of them are really ugly. )

The high number would of course be desireable (not to use all of
them in one plot, but sometimes the piechart-points are just what i
want), although i see this would be a lot of work in every terminal.

Maybe more symbols could be added at minor releases, but the default
repeat cycle kept, so the new ones only appear if they're explicitly
enabled?

I however notice that the windows terminal points 8-15 are sorted
differently than in postscript. wxt is identical to ps, except for
the two missing 14+15.

Perhaps re-sort the windows terminal now, and add the pentagons to
wxt? Then we´d have sixteen identical symbols in many terminals. I´d
settle for that. ;-)

[Font handling]

> It is definitely not possible to offer the same font handling for all
> terminals.  It is not even possible to have a single terminal,
> e.g. libgd+png,  provide the same font handling across different
> operating systems and library versions.
>
> As to Feature Request 363, I agree that it would be nice to clean
> up support for requesting bold/italic/etc.    Since there is no
> consistency in how to capture this in a font name, I suggest that
> a better approach is to extend the exhanced text mode to include
> LaTeX-like markup   {\it{italic text}  and \bf{boldface text}}
> Once the enhanced text code can handle the new tags,
> the underlying matchup to suitable fonts can be added one
> terminal type at a time.  
>
> I'm not sure whether this should hold up version 5, even
> assuming someone is keen to work on it.

The LaTeX-like thing is probably a good idea. That way also
different fonts could be selected. (Have to, in fact, because i.e.
italics are a different font.) In the meantime it´d help if the
individual terminals handled the syntax less strict (some enforce
uppercase first letters on "Bold", some need commas, others spaces,
see FR 363).

That way there should be no issues regarding backward compatibility.

  Karl

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Tait
In reply to this post by sfeam

I'm wishing I'd kept a list somewhere, now. Off the top of my head:

Change the default color sequence
The default colors are poor for accessibility (red-green
color-blindness being the most common, for example), poor for printing
(saturation and color profile conversions), poor for conversion to
grayscale, and don't fit within any of the usual
triadic/split-complementary/etc. color schemes.

Default enhanced mode on
It is more common to get questions about why sub/super-scripts don't
work, and sometimes people don't even realize gnuplot is capable of
non-ascii because enhanced mode defaults off. I think the more common
use case is for users to want the enhanced behavior, and where it is
unwanted users can turn it off for an individual label/title, or for
the entire terminal. It's particularly confusing for a user to "set
title ... enhanced" and then have it not work because they hadn't
previously "set term ... enhanced".

Maybe it's worthwhile CC-ing the Octave developers on this topic?

sfeam <[hidden email]> said (on 2014/03/05):
> Important note:  If there is some behaviour or syntax in gnuplot
> that has been annoying you for the last 20 years, please speak up.
> This is the best chance you will have to get it changed!

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

sfeam
On Thursday, 06 March 2014 01:58:18 AM Tait wrote:
>
> I'm wishing I'd kept a list somewhere, now. Off the top of my head:
>
> Change the default color sequence
> The default colors are poor for accessibility (red-green
> color-blindness being the most common, for example), poor for printing
> (saturation and color profile conversions), poor for conversion to
> grayscale, and don't fit within any of the usual
> triadic/split-complementary/etc. color schemes.

I put in this work already for 4.6.
Apparently it is not well enough advertised.

You can look at the demo collection to see the default color + point
sequence in my installations.  My preferred defaults and two other
pre-coded sets are in the 4.6 distribution package and any build of 4.7.

One of the included sets is taken from
"Palette of colors selected to be easily distinguishable by
color-blind individuals with either protanopia or deuteranopia"
Bang Wong [2011] Nature Methods 8, 441.

I find this one to be a little extreme, so I tweaked it with
the help of a protanopic consultant to generate the one I
recommend for general use.

So what do we have to do to get people to use the new
color schemes - hide the red/green/blue scheme altogether?

Should we introduce a new command:
   set colors {default|podo|monochrome|classic}

Where
        default: my favorite, derived from Wong
        podo: the Wong palette for color-blind individuals
        monochrome: gray scale
        classic: the old ugly red/green/blue

But note that you can do this already in 4.6 using the commands
        load 'colors_default.gp'
        load 'colors_podo.gp'
        load 'colors_mono.gp'

As to greyscale-compatible color palettes, that was the motivation
for adding the "cubehelix" palette options.  This was taken from
D A Green (2011) http://arxiv.org/abs/1108.5083

> Default enhanced mode on

As noted in the announcement, that is indeed the new default.

        Ethan


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Plotter-2
In reply to this post by sfeam
On 03/05/14 19:38, Ethan A Merritt wrote:
> Have you looked at the proposed patch
> "Multiplot auto layout with explicit margins and spacing"?
>
>      https://sourceforge.net/p/gnuplot/patches/611/
>
> Your feedback or testing would be valuable, and I think the patch could
> be added to the code base either before or after the next release if
> people want it.

I have not tested the patch but the ability to have y axis labels on
just the first plot in a multplot row would be a significant feature.
Repeating the axis labels eats up far too much plotting real estate.

This would be a big plus.

Peter.


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Plans for gnuplot version 5

Plotter-2
In reply to this post by Mojca Miklavec
On 03/05/14 23:37, Mojca Miklavec wrote:
> Nowadays I don't see any reason why each terminal should have its own
> set of default colours, dash patterns and point types.


I have also found inconsistencies , especially line colours and line
thickness, inconvenient.

I often work in wxt and then plot png or svg. It's annoying that they
are so different. This can be overcome to some extent by explicitly
defining rgb colour for each plot line etc. but it's a time waster and
gets rather messy.

In fact this tends to mean that I don't use png terminal at all now. I
use wxt clipboard button and past into a graphics editor to save a png.


Obviously, text extent is the other big inconsistency between terminals.
If easing of the strict BC policy ( which is excellent BTW ) for the
jump to v5 allows something to be done about text extent, that would be
a MAJOR improvement.

/Peter


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
1234
Loading...