|
From: Jon G. <jo...@th...> - 2014-03-05 12:38:03
|
> 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 |