On 2015-01-09 16:38-0000 Andrew Ross wrote: > > Phil, > > The problem was that we updated the API and added new functionality that > was never included in the metafiles since no-one was supporting it. In > the end we took the decision to disable it by default rather than > distribute something that didn't work fully. The plrender code is still > there in utils/ if you want to take a look. It would be possible to > resurrect this is someone was enthusiastic enough. > > I always had it in the back of my mind to do a complete rewrite to > make an object oriented structure storing all the plot information. > This would allow complete recreation of a figure, and also allow > editing of labels, data, colours etc. My vision was to implement > something that would allow creation of proper matlab style graphics > in octave, but it would be useful for other things too.
To Andrew and Phil: I also would strongly encourage some volunteer to do a complete rewrite of plmeta and plrender since it is a fundamentally good idea to collect all plot data in a compact binary form and dump that form to disk to be conveniently rendered later (even years later when new devices might be available) by any device driver using plrender. Here is my vision of how this rewrite should be implemented. The binary data written by plmeta and read by plrender should contain at least a file endianness indicator, a version number for the binary format, and a binary plot buffer containing all the plot commands. I bring up the endianness issue because as far as I can tell plmeta and plrender currently completely ignore that issue, and for the rewrite I suggest we deal with the endianness issue similarly to what is done for ephcom (where we store binary data on the disk on one endianness platform and read it from another endianness platform as a matter of course). To follow what ephcom does, the plmeta device driver should write the binary data to a file with no byte swapping, i.e., it should simply use the platform endianness for the file. The plrender utility should be able to read that file back on any endianness platform because it applies byte swapping if necessary to transform the file endianness to the platform endianness. All this endianness logic happens completely transparently so essentially the user can just forget about endianness concerns when dealing with binary data on disk. I also mention "a binary plot buffer containing all the plot commands" in the above description because I suspect the code in src/plbuf.c which is part of our core C library API could be used to deal with such a buffer with complete generality. That is assuming the plbuf.c code is completely up to date with regard to all PLplot features, then plmeta and plrender would also be automatically up to date (unlike their sad current state). I also suspect if the plbuf API was used, then the actual remaining code in a rewritten plmeta and plrender would be quite small indeed. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
