# Plans for gnuplot version 5

69 messages
1234
Open this post in threaded view
|

## Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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 maxmin 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
Open this post in threaded view
|

 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 | ## Re: Plans for gnuplot version 5  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 | ## Re: Plans for gnuplot version 5  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 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 | ## Re: Plans for gnuplot version 5  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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

Open this post in threaded view
|

## Re: Plans for gnuplot version 5

Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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
Open this post in threaded view
|

## Re: Plans for gnuplot version 5

Open this post in threaded view
|

## Re: Plans for gnuplot version 5

 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