Quality Command Line Graphing?
September 29, 2009 6:41 AM Subscribe
Open source, command line, low "impact", png-producing, full-featured, good-looking graphing on Linux and other Unices?
We are using a script (Tcl, if it matters) to generate a script that will be sent in an email. Right now, we are using gnuplot. It's been a source of problems. No one particular thing, we just often have "issues" generating our graphs, many of them attributable to gnuplot weirdness. I'd like to rewrite it more robustly and eliminate gnuplot (on a three-strikes basis).
The "open source" and "command line" are pretty self explanatory. BTW, I don't really consider gnuplot to be command line, because it has its own shell. Yes, you can script it, but I'm looking for something that will take everything (except the actual data) as command line options.
"Low impact" means "not a lot of extra libs required" and is on the list because we have to manage, build and ship this stuff.
"full-featured" means that something that just draws a squiggle isn't enough. The particular graph we are sending out is actually a multiplot, i.e. two graphs in the same image file. We need to be able to label axes, change colors, set ranges, etc.
"png-producing" I think is non-negotiable. Personally, I would be happy to switch image formats (or better yet, go with SVG), but this email has to meet certain other requirements and I dasn't mess with the format.
"Other Unices" include Solaris and Irix. It doesn't have to ship with those OSes, though, as long as it will compile there painlessly.
As for "good-looking": Plotutils is actually perfect, except for one problem: The font rendering (actually, rasterizing) is complete ass. As in nearly unreadable even at reasonable sizes. I actually confirmed this with the maintainer that there is no way to make them look better at the present time.
We are using a script (Tcl, if it matters) to generate a script that will be sent in an email. Right now, we are using gnuplot. It's been a source of problems. No one particular thing, we just often have "issues" generating our graphs, many of them attributable to gnuplot weirdness. I'd like to rewrite it more robustly and eliminate gnuplot (on a three-strikes basis).
The "open source" and "command line" are pretty self explanatory. BTW, I don't really consider gnuplot to be command line, because it has its own shell. Yes, you can script it, but I'm looking for something that will take everything (except the actual data) as command line options.
"Low impact" means "not a lot of extra libs required" and is on the list because we have to manage, build and ship this stuff.
"full-featured" means that something that just draws a squiggle isn't enough. The particular graph we are sending out is actually a multiplot, i.e. two graphs in the same image file. We need to be able to label axes, change colors, set ranges, etc.
"png-producing" I think is non-negotiable. Personally, I would be happy to switch image formats (or better yet, go with SVG), but this email has to meet certain other requirements and I dasn't mess with the format.
"Other Unices" include Solaris and Irix. It doesn't have to ship with those OSes, though, as long as it will compile there painlessly.
As for "good-looking": Plotutils is actually perfect, except for one problem: The font rendering (actually, rasterizing) is complete ass. As in nearly unreadable even at reasonable sizes. I actually confirmed this with the maintainer that there is no way to make them look better at the present time.
Response by poster: Great-looking graphs from both pChart and rrdtool and if this were modern Linux only, I'd be all over rrdtool in particular. But having to compile and install a scripting language or a long list of libs onto an aging SGI or sparc isn't a good fit here.
posted by DU at 7:14 AM on September 29, 2009
posted by DU at 7:14 AM on September 29, 2009
Is building and shipping statically linked binaries out of the question?
posted by Cat Pie Hurts at 7:47 AM on September 29, 2009
posted by Cat Pie Hurts at 7:47 AM on September 29, 2009
Response by poster: No, that's in the question per se, but. The idea is that I'm trying to eliminate a source of bugs by simplifying. Tripling the number of required libraries doesn't really do that. Even if the libraries never go out as separate products, we've still got many more lines of code, more version numbers to periodically check, more interactions to debug, etc.
posted by DU at 9:18 AM on September 29, 2009
posted by DU at 9:18 AM on September 29, 2009
R makes fantastic graphs but may be too heavy-weight for your purposes.
posted by zsazsa at 9:33 AM on September 29, 2009
posted by zsazsa at 9:33 AM on September 29, 2009
Is your objection to a scripting language due to the fact that you think you need an extra separate script file? That's not the case for plotting languages that can take their script via stdin.
echo 'set key left box; set samples 50; set terminal png; set output "test.png"; plot [-10:10] sin(x),atan(x),cos(atan(x))' | gnuplot
I'm not sure how this is inferior to using command line options; it's still something that you can system() (or open(), for a tiny bit more efficiency/compatibility) directly from Tcl.
posted by roystgnr at 10:57 AM on September 29, 2009
echo 'set key left box; set samples 50; set terminal png; set output "test.png"; plot [-10:10] sin(x),atan(x),cos(atan(x))' | gnuplot
I'm not sure how this is inferior to using command line options; it's still something that you can system() (or open(), for a tiny bit more efficiency/compatibility) directly from Tcl.
posted by roystgnr at 10:57 AM on September 29, 2009
Response by poster: No, we are already driving it from a pipeline. There's no one single objection to gnuplot exactly. It's just that this one corner of the program keeps giving us grief and it almost always comes down to some nitpicky thing to do with gnuplot or related libraries.
I find that when a particular section of program is the source of many problems, it's usually best to rip it out and rewrite it from scratch rather than endless squash little issues. And I actually did that with this, replacing gnuplot with plotutils in just a couple hours. Much cleaner, more general and fewer lines of code--all good signs of better code quality. But then I discovered that the font ugliness I thought was just me not passing quite the right options was actually an unavoidable problem.
But I guess it is not to be. Or perhaps I could fix the plotutils rasterizer...? Yeah, like I have time for that.
posted by DU at 11:37 AM on September 29, 2009
I find that when a particular section of program is the source of many problems, it's usually best to rip it out and rewrite it from scratch rather than endless squash little issues. And I actually did that with this, replacing gnuplot with plotutils in just a couple hours. Much cleaner, more general and fewer lines of code--all good signs of better code quality. But then I discovered that the font ugliness I thought was just me not passing quite the right options was actually an unavoidable problem.
But I guess it is not to be. Or perhaps I could fix the plotutils rasterizer...? Yeah, like I have time for that.
posted by DU at 11:37 AM on September 29, 2009
Plotutils can generate postscript output, which you can rasterize with ghostscript.
posted by zsazsa at 12:07 PM on September 29, 2009
posted by zsazsa at 12:07 PM on September 29, 2009
In that case, one other suggestion:
http://matplotlib.sourceforge.net/
In my last "how best to plot this data" hunt I ended up sticking with octave3 for graphs and using gnumeric for a few pie charts, but the above python library was tempting.
posted by roystgnr at 12:11 PM on September 29, 2009
http://matplotlib.sourceforge.net/
In my last "how best to plot this data" hunt I ended up sticking with octave3 for graphs and using gnumeric for a few pie charts, but the above python library was tempting.
posted by roystgnr at 12:11 PM on September 29, 2009
Way, way, way outside of the scope of your question, but, you could always have your script spit its data at a secondary system for graph post processing and hock it back for display. Hell, your company you even turn it into a new little client service revenue stream by providing the processing yourselves. (gah..I spent WAY too much time doing marketing's bidding in my last sysadmin job).
posted by Cat Pie Hurts at 12:29 PM on September 29, 2009
posted by Cat Pie Hurts at 12:29 PM on September 29, 2009
Just a few ideas picked from "apt-cache search plot" in case you haven't done it yet:
Package: epix1
Depends: gs, imagemagick, texlive-base-bin, texlive-latex-base, texlive-pictures
Description: Create mathematically accurate line figures, plots and movies
Package: grace
Depends: lesstif2, libc6 (>= 2.4), libfftw3-3, libice6 (>= 1:1.0.0), libjpeg62, libnetcdf4, libpng12-0 (>= 1.2.13-4), libsm6, libt1-5, libx11-6, libxext6, libxmu6, libxp6, libxpm4, libxt6, xmhtml1, zlib1g (>= 1:1.1.4), gconf2 (>= 2.10.1-2), gsfonts (>= 6.0), defoma
Description: An XY plotting tool
Package: plplot-bin
Depends: libc6 (>= 2.3.4), libcsiro0 (>= 5.9.0), libfreetype6 (>= 2.3.5), libltdl7 (>= 2.2.6a), libplplot9 (>= 5.9.0), libqhull5
Description: Scientific plotting library (utilities)
Also an interesting hit: tklib has a Plotchart function.
posted by pwnguin at 6:16 PM on September 29, 2009
Package: epix1
Depends: gs, imagemagick, texlive-base-bin, texlive-latex-base, texlive-pictures
Description: Create mathematically accurate line figures, plots and movies
Package: grace
Depends: lesstif2, libc6 (>= 2.4), libfftw3-3, libice6 (>= 1:1.0.0), libjpeg62, libnetcdf4, libpng12-0 (>= 1.2.13-4), libsm6, libt1-5, libx11-6, libxext6, libxmu6, libxp6, libxpm4, libxt6, xmhtml1, zlib1g (>= 1:1.1.4), gconf2 (>= 2.10.1-2), gsfonts (>= 6.0), defoma
Description: An XY plotting tool
Package: plplot-bin
Depends: libc6 (>= 2.3.4), libcsiro0 (>= 5.9.0), libfreetype6 (>= 2.3.5), libltdl7 (>= 2.2.6a), libplplot9 (>= 5.9.0), libqhull5
Description: Scientific plotting library (utilities)
Also an interesting hit: tklib has a Plotchart function.
posted by pwnguin at 6:16 PM on September 29, 2009
Response by poster: epix and grace look too heavyweight on the face of it. I haven't yet eliminated plplot, thanks for the tip.
Also, as mentioned plotutils would be perfect if it weren't for the rasterization problem. A coworker wondered if it could be ported to use Cairo instead of libxmi. FYI.
posted by DU at 3:22 PM on September 30, 2009
Also, as mentioned plotutils would be perfect if it weren't for the rasterization problem. A coworker wondered if it could be ported to use Cairo instead of libxmi. FYI.
posted by DU at 3:22 PM on September 30, 2009
« Older "Soft in some places, lumpy in others. It's... | Does an NFL placekicker have better distance at... Newer »
This thread is closed to new comments.
posted by Cat Pie Hurts at 6:50 AM on September 29, 2009