Thanks for the overview, Stuart. Very useful. However, I am not having any luck finding many of the packages you mention in etch; xmggrace, qtiplot, and pyx in particular don't turn up on a cursory search of packages in etch. Are they maybe included in packages under different names?
I am a long-time Matlab user that is trying to migrate to Octave but have been having some issues with plotting. Octave by default uses gnuplot, which I think produces very satisfactory plots, but with which I have been having quite a bit of trouble exporting the plots to useful files. Octave also has support for plplot (which I noticed was not on your list), but I have no experience with it. Do people have any suggestions for producing nice plots from Octave? Has anyone figured out a good way to print gnuplot plots produced with Octave? What about peoples experience with plplot? Thanks in advance for any advice. jamie. On Thu, Oct 13, 2005 at 01:57:38PM +1000, Stuart Prescott wrote: > Hi all, > > A question that has come up a few times on this list is how people go > about producing publication quality graphs. I'm revisiting this question > as I'm yet to find a method that actually works for me. Part of this is > that I am used to doing things in a particular way (which might have to > change!) and part of this is shortcomings in various packages that I've > tried. After a day or so of frustration with any given app, I end up > going back to Origin (Origin6 under WINE mostly works). > > Here, I'd like to describe how I normally plot data and why the various > apps that I've tried don't work for me (below). > > Hopefully, this will incite some discussion and regular users of these > apps can suggest some add-ons or simple changes to my workflow that will > turn them from being a pain in the backside to being a useful utility. > Or perhaps this will encourage someone (me?) to hack at these apps until > they become more useful to people like me. > > All comments welcome! > > cheers > Stuart > > > > * current workflow using Origin > I normally have data from a number of different (but related) > experiments in the one file (perhaps X1 Y1 X2 Y2 or X Y1 Y2 Y3) format > that has been exported from OOo.calc or excel or perhaps from a data > analysis program that I have written for the purpose. The files are > usually tab-delimited and I can just Import ASCII in Origin and all is > well. It sets the column names to be the headers from the text file. I > can then create plots with some or all of the data and will frequently > want to add new data to a plot from another worksheet trivially etc. In > the end I produce an EPS graphic for use in LaTeX or a PNG graphic for > MSWord/MSPowerpoint. I like the "project" paradigm of Origin where data, > settings and graphs are all together allowing you to add new data to > plots, plot things in different ways etc. I don't just make the one > final publication quality graph in an Origin project; rather, I usually > have several different publication graphs in the one project (and often > both print and presentation versions of these graphs too) as well as > other graphs made while I explore the data. I tend not to use Origin for > data manipulation as it is much more cumbersome than using a proper > spreadsheet program like excel or OOo calc. > > * OOo calc > Ha. Nice thought. Produces graphs that look as bad as M$Excel but can't > even handle X1 Y1 X2 Y2 data (only X Y1 Y2). Non-starter even for just > having a "quick look" at data, even if it does meet the "project" > paradigm. > > * xmggrace > It can't read in any of my data files. Bit of a showstopper, really.... > I almost always have data with columns: X Y1 Y2 Y3... or X1 Y1 X2 Y2 X3 > Y3... and I *always* have text column headings labelling the data. It > chokes on this sort of thing and I'm not going to manually import > hundreds of individual files (or columns piped through tail +1 | cut -f > etc) through that tedious import dialogue. > > * qtiplot > In a file with X1 Y1 X2 Y2 etc where the data streams are different > lengths, it chokes... all the data is left-aligned in the import (i.e. > if X1 Y1 has 20 rows but X2 Y2 has 30 rows, X1 Y1 will "gain" an extra > 10 rows of data at the expense of X2 Y2). It also doesn't permit you to > define multiple X columns per data sheet or edit an existing plot to > change which column is to be used for the X or Y data etc (which is > useful in transferring settings from one plot to another in the absence > of styles or templates). Finally, the plots don't scale to the size of > the window (there is no defined "page" size) so if you make the window > bigger, then you have to manually increase all the font sizes yourself. > > * labplot > Shares many of the same bugs/problems as qtiplot. But you also can't add > a new curve to an existing graph unless you read it in from a data file > directly or it is a mathematical function (i.e. you can't use data > already in a data sheet). Column headers are also discarded so you'd > have to go back and relabel all the columns. (OK, on the 1 week time > scale you can just remember them, but on the 1 year timescale you need > them labelled, and I always assume that i'm going to have to come back > to it on that timescale as it can be that long between doing the work > and publishing it.) It also can't generate smooth curves (e.g. splines) > between data points. > > * scigraphica > Importing X1 Y1 X2 Y2 data into a sheet causes the data to be truncated > at the number of rows in X1. Column headers are imported, but if more > than one column has the same name then only the left-most column is used > when you come to graph that dataset. > > * gnuplot > I'll confess that I have a deep seated aversion to gnuplot that dates > back to my undergraduate days which is probably unfair. Having said > that, I do prefer to be able to manipulate the graphs in real time *and* > be able to save the settings and data as a project. With gnuplot you can > do one or other (either run it from a script which is pretending to be a > "project" file or some sort, or you can do it in real time.) > > *gri > Works great for me for quick scriptable graphing to condense the data > from several hundred simulations into a few graphs with minimal work. > But you can't quite get production quality graphs out of it (e.g. you > can't have non-italicised subscripts or superscripts). > > * pyx > This has the same non-real-time and non-project problem of gnuplot, but > I have to say that of all these utils, this is the one I am most like to > adopt. I was able to get much better results with this than the other > tools, mainly because it can read in arbitrary data structures. But I'm > not sure it's really sustainable for long-run usage as configuring a > plot that isn't *quite* what you want is a huge amount of work. The > biggest problem I had (showstopper!), however, is that it can't generate > any form of non-linear line between data points (e.g. spline or > b-spline). That makes for unacceptably ugly graphs. > > * others? > Are there any other utils that you can suggest that might meet my > requirements? I'm happy to try things out and will post back reviews of > them too when I have a chance. > > > ** conclusions > The two main things that I can condense out of this are that: > > * there is nothing in linux land that even comes close to Origin for > flexible scientific graphing and data management. That's a pity... linux > leads in everything else, but I know very few other people who will put > the sort of time in that I have done in trying to get this to work. > > * the X1 Y1 X2 Y2 data format is a problem.... many of these utilities > would work better if I wasn't using that. However, dropping that format > comes at the expense of me having to do a lot more work to split up > files and then import them individually. > > * generating smooth-curve data is a problem... I'll play around with > spline(1) from the plotutils package and aspline(1) from the spline > package to see if that could be a viable filter. But having to filter > all the data through an external spline program is somewhat suboptimal. > Perhaps there is python module for this that will work with PyX? > > > > (Note that this is not to say that Origin is without faults. Apart from > the idealogical reasons for moving to free software, the EPS export in > Origin6 doesn't clip the data to within the axes which was the final > motivation for me looking elsewhere. Eventually, I found a workaround > by printing to a PS file and then using ps2epsi but that's not a great > solution.) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
