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

Re: Plans for gnuplot version 5

[Juhász P. <pet...@gm...>]

On Wed, 2014-03-05 at 15:02 -0800, Ethan A Merritt wrote:
> 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.
> 

While I maintain that the existing state of affairs with
linetypes/linestyles is unfortunate, I have to concede that it is indeed
to late to change it. Their current, confusing definitions have been
given too early in the history of the project.
The problem with my proposal, now that I think about it, is that most
interactive terminals default to non-dashed mode, so for these, the
linetype setting would indeed become a no-op as per the default
settings.


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

It would in the sense that the default dash patterns would conceivably
be uniformized across the capable terminals, so some of them would
produce different plots.

> > Also, may ask what is your proposed timeline for 5.0?
> 
> That's what I'm trying to determine.
> 

OK, I rephrase the question: what's your latest preferred date for the
final release? End of this year perhaps?
I think it would be beneficial if you set a tentative date because then
potential contributors would be able to gauge whether their proposed new
features are plausible within that timeframe.

Peter

Re: Plans for gnuplot version 5

[<pl...@pi...>]

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.

Re: Plans for gnuplot version 5

[<pl...@pi...>]

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

Re: Plans for gnuplot version 5

[sfeam <sf...@us...>]

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

Re: Plans for gnuplot version 5

[Tait <gnu...@t4...>]

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 <sf...@us...> 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!

Re: Plans for gnuplot version 5

[Karl-Friedrich R. <mai...@gm...>]

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

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

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

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

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

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

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

Re: Re: Plans for gnuplot version 5

[Mojca M. <moj...@gm...>]

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

Re: Re: Plans for gnuplot version 5

[Karl-Friedrich R. <mai...@gm...>]

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

Re: Plans for gnuplot version 5

[Juhász P. <pet...@gm...>]

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

Re: Plans for gnuplot version 5

[Bastian M. <bma...@we...>]

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

Re: Plans for gnuplot version 5

[Jon G. <jo...@th...>]

> 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

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

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

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

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
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: Plans for gnuplot version 5

[Ethan A M. <sf...@us...>]

On Wednesday, 05 March, 2014 08:22:25 pl...@pi... 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.

Re: Plans for gnuplot version 5

[Jon G. <jo...@th...>]

> 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

Re: Plans for gnuplot version 5

[Liu G. <goo...@gm...>]

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!

Re: Plans for gnuplot version 5

[<pl...@pi...>]

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.

Plans for gnuplot version 5

[sfeam <sf...@us...>]

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

Re: Repository conversion

[Tait <gnu...@t4...>]

Daniel J Sebald <dan...@ie...> said (on 2014/03/03):
>  From my understanding, the reason that git is more flexible in terms of 
> modifying past comments as pointed out by Mojca is fact that the 
> underlying manner in which files are stored in git is as complete files, 
> albeit hash files.  On the other hand, hg uses a series of diffs.  Thus 
> hg is in more sense "immutable".

I wouldn't get hung up on the difference between snapshots vs. change
sets. Assuming everything is working correctly, the two should be
equivalent. (If anything, I would say that capturing exactly the state of
the repository as it was for the developer making the commit is more
"immutable", but either approach will achieve the same end result.)

>                       ...  So, once a push is done and considered 
> public, it is best to be immutable.

This is true for either Mercurial or Git.

> ...                    For me, the two differences that stood out when I 
> compared git and mercurial years ago (git I have limited exposure with 
> since):
> 
> 1) I found hg's syntax more understandable and less cumbersome.  I 
> didn't like the staging area concept of Git because it felt repetitive, 
> although I'm sure there might be some simple ways of circumventing this 
> staging area because git does provide so many options/configurations. 
> So please point out if that is still true and a big difference between 
> the two systems.

Terminology is different (update vs. fetch/pull, clone vs checkout, etc.)
but these hurdles are trivial and will be forgotten within a couple of
weeks anyway.

The staging area and index still exist in git, and as I mentioned before,
it is a big difference that sets git apart from other tools. It is
possible to set up git aliases and habits to make the index (aka staging
area) less apparent, but if it's possible to forget the "bad habits" of
CVS and SVN one may find the index is not just useful, but essential.
There is convenience: often one finds themselves working on more than one
thing at a time, or realizing midway through a change that it ought to
instead be multiple, smaller pieces. But also there is the philosophical
argument: one ought to deliberately construct a commit, not have it thrown
together as the summation of whatever -- intentionally or not -- happens
to be different.

The counterargument, as you've pointed out, is that I can be careful and
manage my work tree myself to construct the commits I desire, thank you
very much, now please stop making me repeat myself.

I guess the agnostic would say that in one case the tool relies on you to
manipulate the filesystem to create the desired changesets (that's
Mercurial), and the other provides tools to more directly craft the
desired commit state (that's git).

> 2) Mercurial has a built in html server that I really like.  Does git 
> have that now?  I really like being able to go to some project's 
> repository online and there is that similar, nice interface for finding 
> info about recent changesets, browsing code, viewing file history, etc. 
>   That really is an important part of source control.  (One of the 
> nicest VCS's in terms of visual navigation is a commercial product, but 
> isn't a distributed VCS but more along the lines of cvs.)

Git has had a built-in web server for a long time (since mid-2006). It's
a functional, albeit not terribly pretty interface. That's balanced out
by git having much better local tools for finding info about changes,
browsing code, viewing file history, and so forth so relying on an
external web interface is not necessary. These days, github may well be
the best-known "web interface" to git, but it's obviously tied to github.

In gnuplot's case, that interface is provided by SourceForge, and the same
regardless of tool choice. So I don't think this is really a factor in the
decision. And even if gnuplot moved away from SourceForge, the
public-facing web interface would most likely not be provided by the one
built-in to either git or Mercurial.

> Recently I've discovered tortoisehg which is a very nice interface for 
> Windows users especially.  I assume there is a tourtoisegit as well. 

Yes. And other implementations that similarly integrate into the Windows
shell. And projects for Eclipse. And the usual command-line clients in
either msys or cygwin flavors. I don't think there's any noteworthy
difference between the two on this front.

> So, for Windows developers, hg and git look-and-feel differences might 
> hardly matter.

I don't think preferences among Windows developers will be any less
intense or uniquely personal than any other OS. No UI will make one
indistinguishable from another unless it forgoes the best parts of both,
leaving only a lowest common denominator. (And then, why not just stick
with SVN?)

>                 Also, a good merge tool is worth considering, but I 
> think that might independent of the git/hg question.

I'm not sure if you mean a tool for visualizing and managing diffs and
merges manually, or the algorithms driving merging within the VCS.

For the former, I've recently discovered Meld (http://meldmerge.org), and
I rather like it.

For the latter, git uses true 3-way and N-way merging, with some choices
of variations to those algorithms. Mercurial is using a true 3-way merge
as well now, although nobody seems to know what algorithms they use to do
it. (Darcs' more complex patch and merge algorithms seems to be considered
the best, fwiw.)



At the risk of carrying on too long, here's some questions you didn't
ask:
1) Why do we have version control? Who uses it?  What do they expect out
of it?

2) What's the normal work flow in the project? How are bugs fixed (to the
current version, previously released versions)? How are new features
added? What are the things that work really well or really poorly about
this process?

3) How are outside contributions accepted? (How often does this happen?)
Who deals with these, and how? What works really well or really poorly
about this process?

The answers to those questions are important, I think, to picking git or
mercurial.

Re: demo/plugin Makefile is not derivative of configure

[Daniel J S. <dan...@ie...>]

On 03/02/2014 07:17 PM, Hans-Bernhard Bröker wrote:
> On 01.03.2014 23:42, Daniel J Sebald wrote:
>> I've tried to build gnuplot in a directory other than the "src"
>> directory but it failed because the demo/plugin/Makefile is missing from
>> the "build" directory.
>
> That should be fixed now. I want ahead and had demo/plugin/Makefile go
> through both automake and autoconf.

Builds here, both inside and outside source tree.

Thanks,

Dan

Re: demo/plugin Makefile is not derivative of configure

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

On 01.03.2014 23:42, Daniel J Sebald wrote:
> I've tried to build gnuplot in a directory other than the "src"
> directory but it failed because the demo/plugin/Makefile is missing from
> the "build" directory.

That should be fixed now.  I want ahead and had demo/plugin/Makefile go 
through both automake and autoconf.

Re: Reworked qt terminal is much faster – and fails to work on Mac

[Daniel J S. <dan...@ie...>]

On 03/02/2014 07:02 PM, sfeam wrote:
> On Monday, 03 March 2014 01:41:06 AM Mojca Miklavec wrote:
>> On Sun, Mar 2, 2014 at 11:28 PM, Daniel J Sebald wrote:
>>>
>>> I wrote a clean patch which I placed here
>>>
>>> https://sourceforge.net/p/gnuplot/patches/653/
>>
>> I first faced problems with "plugin"
>>
>> Making all in plugin
>> /bin/sh: line 0: cd: plugin: No such file or directory
>
> That's a totally separate problem.
> The new .../demo/plugin directory is not being handled properly
> by autoconf/automake.  I don't know how to fix it, but the answer
> for now is to use
>   ./configure --disable-plugins
>
>> but after manually patching the Makefile (there is a fair chance that
>> my setup is semi-broken in that respect, so I don't blame the sources
>> until I do a few more tests from a totally clean CVS checkout), here
>> are the initial problems again:
>>
>> gnuplot>  plot sin(x)
>> qt_sendFont: Not receiving font properties
>> qt_sendFont: "QLocalSocket: Socket operation timed out"
>> gnuplot>  qt_processTermEvent received a GE_fontprops event. This
>> should not have happened
>>
>> The plot finally appears after 15 seconds, without any labels, wrong
>> window size (that's also a problem in trunk/HEAD). Gnuplot then never
>> properly recovered (I never got any text labels).
>>
>> The second gnuplot run works.
>>
>> These are exactly the symptoms that Ethan fixed recently.
>
> Yeah. I put my comments on the patch tracker, but in short the patch
> removes exactly the fixes I put in to handle the slow OSX font response.
> So I don't think this patch is going in the right direction for event
> handling.
>
> The initial fork+and wait of the external process may be cleaner in
> Dan's patch than it was before.  But I think we should leave the event
> handling the way it is now.

OK, it's easy enough to pull out the few hunks for fork/wait and create 
a separate patch.

Dan