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