> once you get the SVG, you're home free in terms of making high quality print
I know that David and I have discussed this capability for Prima. He has been busy with $work lately. At least knowing that he believes that "in concept" that should be possible is nice. Cheers, Joel On Thu, Jan 31, 2013 at 4:01 AM, Craig DeForest <[email protected]>wrote: > I put a lot of energy into making the Gnuplot stuff work, because it > produces beautiful publication-quality output in both 2-D and 3-D and is > reasonably fast. I see the current round of grousing as a Good Thing, > shaking out the module as people try it out. There are some architectural > worries on Microsoft Windows since it is not POSIX, but I don't see them as > show-stoppers - interprocess control is universal, and I am positive the > low-level communication with gnuplot can be made more robust on that > platform. I do not see gnuplot succumbing to bit rot in the near future - > it has a vibrant development community and is being actively supported for > multiple major platforms with far more users than PDL. > > The main issues with gnuplot are that is not optimized for interactive > work, and that the API is a bit ... crufty. Those things are OK for most > stuff, in part because plotting is very fast for most types of plot, but > there are two large gaps I see, that are not likely to go away soon: > > * The architecture slows down large image display. This makes it awkward > to, e.g., perform interactive markup on large images. Up to about 800x800 > is okay on my macbook pro, but 4000x4000 floating point images take around > 10s to render, and the architecture forces a full re-render after each new > point is rendered to the screen by, e.g., read_polygon(). The slowness > arises partly because Gnuplot hands the image around a lot internally and > partly because the image has to go through a pipe from PDL to Gnuplot each > time. > > * It is likely to remain awkward to incorporate a gnuplot widget into > other types of window - at least, without someone diving in and writing a > new backend device driver for gnuplot itself. > > The API concerns stem partly from Gnuplot having a long legacy and partly > from the fact that plotting itself is a complex endeavor - supporting all > the wizzy things that gnuplot does requires a certain amount of cruftiness > and wooliness to the control interface - every plotting package I have > studied (IDL, Mongo, PGPLOT, Vplot, and some of Plplot) ends up pretty > wooly in the course of becoming versatile. > > I see Prima as a very nice step in the direction of interactive work, > potentially enabling a graphical PDL and certainly enabling closer > interaction with graphical data. There is a lot of architectural beauty in > it, although it does not yet fulfill my needs as an academic user - it is > more of a toolkit than a high level plotting package. (To be fair, this > seems to be the state of Plplot too... at least the last time I dug into it > in anythibg resembling detail...). > > I see Gnuplot and Prima both as viable directions forward. I suggest > moving toward Gnuplot as a primary plotting interface, and am willing to > support frequent releases of it as folks begin reporting desires and/or > warts that are invisible to me. I also suggest maintaining Prima as a > major alternate package with prominent advertisement, in part because its > tight integation with Perl and PDL give it a lot of promise for future > interactive tools. > > I would like to see us keep legacy support for PGPLOT and Plplot, so that > people like Karl (or even me) can continue runnng old code - but I do not > think it is productive to feature those packages prominently in, e.g., the > examples and tutorial literature. > > > (mobile) > > > On Jan 31, 2013, at 1:27 AM, Matthew Kenworthy < > [email protected]> wrote: > > > >> i'm going to be an instigator again and point out that pgplot, plplot, >> and gnuplot are all ~20 year old pieces of legacy software. at least >> gnuplot is actively maintained and evolving, but pgplot has hardly been >> touched in ~10 years. i've tried plplot a few times, but always ended up >> throwing up my hands after a short while. maintaining dependencies with >> packages like these will always be a headache and will hold back adoption >> and evolution of PDL. note that i haven't looking into prima at all, >> however. >> >> > 20 years old doesn't mean they're crap - but your point about legacy > software is a good one. > > tying back into the previous discussion about notebook-type interfaces >> like what ipython has i'd like to point out the existenceit of >> http://d3js.org/. ipython notebooks are great, but using matplotlib >> graphics within a browser is rather limiting. integrating something like >> D3 opens up a lot more flexibility and capability. a browser-based PDL >> shell that used D3 for plotting could be pretty kick butt.... >> >> > I use plotting packages for two things - making production quality figures > where I want fine grained control, and 'rough and ready' plots that allow > me to hack at data on the command line, like the python notebooks. > > d3js looks *beautiful* for interactive data, but probably a pain in the > ass for reproducible PDF output. What do you use for paper output? > > Matt > > > > -- > Matthew Kenworthy / Assistant Professor / Leiden Observatory > Niels Bohrweg 2 (#463) / P.O. Box 9513 / 2300 RA Leiden / NL > > _______________________________________________ > > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > >
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
