Custom Charts w/ Perl and GD
An anonymous reader writes "This article describes techniques you can use to create new levels of usefulness in your dynamically generated charts with Perl and GD. Cook up some automatically generated graphs for your organizational meetings or live enterprise directory data. Annotate the charts with readable text that delivers more information than the standard pie chart. Using the power of GD and Perl, you can link various data and images together to create sophisticated charts that will help bring visual interest to your applications."
Ah, the summary was so close to getting the words 'perl' and 'readable' in the same sentence (possibly for the first time), but just couldn't quite pull it off.
ccalam - acoustic versions of new songs.
The code looks easy enough to experiment with your own artwork, so I look forward to seeing how much better you can do.
waiting for ad.doubleclick.net
I don't know man, they have a donut chart on there with some pretty serious graphics laid into it. That beats most other articles with their plain Jane donut charts, these ones have upper management written all over them.
Maybe they should email a link to Edward Tufte...amybe he'll be insterested. Data graphic geniuses these folks.
"Sacrifice for the good of The State" - The State
If that's still not tickling your fancy then I would suggest matplotlib which is actually pretty versatile, and produces good looking plots. There's also PyX if you're looking for slightly more raw graphical interaction with nice output. Truth be told, however, after messing around with many of the same options you have, I've found that Gnuplot, once you get over the initial learning hurdle and figure out how to turn out nice looking plots, is the fastest and easiest way to turn out plots and charts.
Craft Beer Programming T-shirts
The code is out there. Whenever the graphics folks want to start contributing, they can.
I can throw myself at the ground, and miss.
...that pie charts are evil. However there are exceptions, like this one: http://themot.org/gallery/d/58721-1/pacmanchart.pn g. Most informative.
Remember how programmers always talk about using the right tool for the right job?
If you want to do something like graphing, then why not learn a language like R, where you can easily and interactively create amazing visuals in very little time? I write code in Java, python, bash, and interact with Oracle and MySQL database. R fits in as a nice way to visualize data, and it's very easy to script up solutions that you can plug into your programming pipeline.
Check out http://addictedtor.free.fr/graphiques/index.php for examples (with source code)
Yeah, it does seem a bit overkill.
If you're organization is so dynamic that your org. chart NEEDs to be generated at runtime by a script on your web server, then maybe writing perl scripts to auto-generate org charts shouldn't be your highest priority.
Freedom is the freedom to say 2+2=4, everything else follows...
I agree with what you're saying, but I think you've got the onus wrong. As someone with design and coding experience, I can say that FOSS programmers often bend over backwards to package things nicely, but are often rebuffed by non-programmers if the interface is not 100% to their liking.
There is a disconnect, but IME it comes from people who think that being a user entitles them to sit back and wait for manna to drop from heaven. The bottom line is simply this: If you're going to work in FOSS, then you have to get your hands dirty. This almost necessarily means learning a little about areas that are not your forte. In order for there to be reasonable cooperation, we need to speak the same language. In the Perl community especially, there is a real desire to learn new things and share knowledge, but if designers et alia aren't willing to learn at least a little Perl, then there's not much to be done.
"Don't make me look at code" is, unfortunately, not often a valid condition for any FOSS participant, regardless of their other talents.
Crumb's Corollary: Never bring a knife to a bun fight.
That's the stupidest comment that gets repeated about all sorts of things in Open Source. There are people who can document, who can theorize and who can draw much better than they can code. If coders and those who can't code but have potential for contribution would communicate, we'd end up with better software. Software isn't just code, sorry to say. Yes yes, "show me the code" is a great line, and wrong for almost everything outside libraries and kernel space (and even then, some documentation writers, theorists and idea people should be involved more than they are by the coders).
- Michael T. Babcock (Yes, I blog)
I do most of my work in Perl, and the lack of a good chart package has been annoying for a very long time. GD::Graph will give you very basic (and not terribly ugly) line and bar charts relatively quickly, but that's about it; it's missing even rudimentary features that make it less than useful (eg error bars).
There just isn't a general purpose charting package for Perl that would even come close to JFreeChart. Grace can produce some nice results, but the Perl interface to it is just a wrapper around their terrible command line interface (maybe it's improved in the last few years, but when I tried it it was almost entirely undocumented and nigh-unusable).
So, if you want publication quality charts you basically still have to learn gnuplot, which is great, but sometimes just a little too involved.
At least this thread gives a nice summary of what the other languages have to offer: the PHP and Ruby packages aren't faring any better, but Python's matplotlib looks freaking beautiful.
sic transit gloria mundi
octave + gnuplot + LaTeX = absolutely beautiful plots in anything I submitted (homework assignments, term papers) in grad school.
.eps files through epstopdf, write some document in LaTeX that included your plots by their basename (i.e. without the .pdf extension in the document), and use pdflatex to generate a nice PDF file complete with clickable cross references
To get you started (there could be errors here, I'm doing this from memory, but Octave code something similar to this:
plot blah
hold on
plot something
plot otherstuff
hold off
gset term postscript eps color 22
gset output someplot.eps
replot
gset output foo %bad shit happens to your plot output if you don't change the output file when setting the term back to X11
gset term x11
Would do the following:
Plot multiple things in a plot to the screen
Output that plot to an EPS file
Reset the output so the next plot would go back to the screen
You could then run the
(There are a lot of details I'm not mentioning here of course, unfortunately there really isn't any single good central HOWTO for doing all sorts of useful stuff in LaTeX.)
retrorocket.o not found, launch anyway?