David could talk about this more than I, but it is my personal view that to get production quality graphics from PDL::Graphics::Prima what is needed is a subclass of Prima::Drawable that emits SVG. There is even an example of this as there already exists a subclass that emits PostScript (Prima::PS::Drawable).
Once PDL::Graphics::Prima would be able to emit SVG, any futher changes to the exported figure could be accomplished in your favorite SVG editor, like say Inkscape. The hardest part of making a plot is plotting the data. P:G:P can already do that; the features that it is missing could often easily be added by hand in an SVG editor. In this way I feel that SVG output could immediately launch P:G:P to production level. If someone has some spare tuits and a little knowledge of XML/SVG this would be a great addition. I suspect it would even be something that the Perl Foundation would consider funding (when properly phrased) since it would help two large CPAN projects. Again, David could probably better comment on both the difficulties in creating such facility, and the utility of doing so. Cheers, Joel On Thu, Jan 31, 2013 at 12:19 PM, Craig DeForest <[email protected]>wrote: > > > I don't like the idea of an interface layer with a generalized front-end, > although I supported it some years ago when we were talking about a > PGPLOT/PLPlot unified interface. Firstly, it adds cognitive overhead for > advanced users (who have to learn two different interfaces); secondly, it > makes everything more bloated and slow because of the translation layer; > thirdly, it adds the potential for more bugs and more bug-shooting grind, > because there always seem to be places where the interface doesn't hold > perfectly. > > Meanwhile, I'd far rather that the limited manpower we have goes into > improving Prima and Gnuplot, rather than hammering them into a fake-o > common interface that was a bit of a kludge to begin with. > > I do think that, if and as Prima development continues, it should become > the go-to platform for PDL graphics. It appears fast enough to do things > like on-the-fly animation and interactive GUI pane work, and it also links > directly to Perl using the XS mechanism, rather than using > potentially-more-buggy IPC -- so the long-term prospects are rosy provided > that we can pull enough mindshare into it. I think it would be worthwhile > to actually architect, rather than grow, a high-level API for it. I have > yet to see a plotting package with a well-architected high-level interface. > > > > On Jan 31, 2013, at 9:53 AM, David Mertens <[email protected]> > wrote: > > I am very busy and could write at length on this topic, but I must be > brief. > > First, I am unahppy with my own rate of progress with > PDL::Graphics::Prima. I feel very positive about the library, but I feel > pulled in so many directions, both within the project and with other > projects, that I have a hard time delivering requested features. I really > wish I could take a week or two and just knock it out, but that is not the > case at the moment and may not be the case until this summer. > > I am going to propose a different take on this. Why don't we actually > flesh out the common plotting commands we would like to see supported > across both Gnuplot and Prima? Then we can write a module, > PDL::Graphics::2D, which pulls in whatever modules are available for this. > I would write the Prima backend, Craig could write the Gnuplot backend. > Doug or Zentara could write the PLplot backend. This, at least, would > suffice for the quick plotting needs. It may be more difficult to make > publication quality plots with this front-end, but we can at least address > the users' need for a basic interface. > > Lacking any other ideas, I would suggest emulating the PGPLOT interface, > since there seem to be a lot of PGPLOT users in the PDL user base. Once the > users learn the ::2D interface, they can read the library-specific docs for > a transition guide to using the direct library bindings when they need it. > It also provides a simple transition point between two different libraries > if a user needs that. > > David > > > On Thu, Jan 31, 2013 at 9:02 AM, Chris Marshall <[email protected]>wrote: > >> Hi All- >> >> Nice to see the discussion of the issue active >> again. I think it is critical to the growth and >> success of PDL that there be some plotting >> capability that is always "in" PDL in that it >> builds and operates correctly on all the PDL >> platforms: win32, MacOSX, linux/unix/bsd/.. >> >> Here is a summary of my experiences with the >> various ones over the years: >> >> PGPLOT: tried and true but not open source. >> It was always a good default (especially if I >> could build the RGB color patched version). >> Interactive drivers for win32 are a bit sketchy >> and for the latest cygwin on win7, the xwin >> driver now hangs which makes it unusable >> for me now. >> >> PLplot: looked to be a possible replacement >> for PGPLOT but I've never successfully built >> it on cygwin nor been able to try the PDL >> bindings. I hope to give it a try with the current >> cygwin to see if things are better. >> >> TriD: good basic 3D visualization but needs >> better control of the visualization parameters >> (e.g., turn axes on/off, labels on/off,...). I have >> had this on my todo list for quite some time >> but at a lower priority to getting PDL working >> cross-platform---especially with a goal of >> increasing the user base on win32. >> >> Gnuplot: the initial bindings by Dima and >> Craig work ok for line plots on cygwin/win7 >> and SPP on win7. Unfortunately, I was >> completely unable to display an image >> in my first attempts. If the robustness on >> PC platforms were improved with some >> usability improvements resulting from >> actual user feedback, I think this option has >> the best chance at the publication quality >> graphics and ok for use interactively. >> >> PDL::Graphics::Prima: this is a fast, interactive >> drawing module with much potential. It has >> the advantage of speed, portability, an >> associated GUI toolkit which could be used >> to embed graphics or design user interfaces >> for PDL apps. I think with a few iterations >> of PDL::Graphics::Prima::Simple would become >> a friendly, available everywhere PDL is, baseline >> graphics and GUI option for PDL. >> >> I like the Prima interactive much better than >> Gnuplot and with the capability of supporting >> OpenGL in Prima (already, thanks Dmitry!) >> we should be able to support TriD graphics >> and even something like buffer graphics >> drivers for PGPLOT, PLplot, and Gnuplot. >> >> Then there are the excellent ideas from Tim >> regarding some type of workbook support. >> That would tie in nicely to the opengl-unified >> structure in that any or all of the graphics >> could be output as a memory buffer (a.k.a., >> a piddle and used for display or imaging). >> I think HTML5 has support for OpenGL >> type graphics. >> >> All very cool! Need more 'round tuits'... >> >> --Chris >> >> >> On Thu, Jan 31, 2013 at 2:54 AM, Matthew Kenworthy >> <[email protected]> wrote: >> > Hi all, >> > >> > Based on the past few days of posts, I'd like to open up a thorny issue: >> > >> > Do we have a plotting package that installs smoothly across all three >> major >> > platforms? >> > >> > I've been playing with python and matplotlib for a couple of months >> now, and >> > although the OO interface is a royal pain, at least I know I can send a >> > script to students/collaborators and it will just *work* for them. >> > >> > I've seen that PLplot is throwing up errors for some people, and now we >> have >> > Gnuplot grumbling as well. PGPLOT is still difficult to install and not >> > interactive-friendly.... >> > >> > If we want more PDL adopters, we should pick a plotting system and put >> all >> > our energies in making that work flawlessly for a couple of years, so >> that >> > interested people don't get discouraged. >> > >> > I also have a selfish reason - if we choose something other than >> PGPLOT, it >> > means a rewrite of the PDL Book, and I don't want to make the >> investment of >> > time if we suddenly decide that 'oops, $PLOTTING_SYSTEM isn't working >> > anymore/new shiny thing is the way to go'. >> > >> > I'd be happy to get any plotting package working for the SciPDL Mac >> binary >> > working, if we get a general consensus here. >> > >> > 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 >> > > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > _______________________________________________ > 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
