So if we are going to go down the route of restoring metafiles then I think I
agree with most of what you just said Alan. Some other points I would like to
add though and some things I'd like to discus.
I strongly agree with utilising the plbuf code. It is pretty current, but not
perfect - I think there are some commands written to the buffer that are not
correct when read back and I think some font stuff isn't recorded for example,
but as this code is actually used by the interactive drivers it should be fixed
anyway.
I also think the buffer needs to include the total length for each instruction
this will help us when developing and aid backwards compatibility as unknown
commands can be skipped without corrupting the buffer.
I agree about the endianness, it should be dealt with and the way you suggest
works for me.
Another associated issue is floating point values. Here we have two issues,
first that a build may use double or single precision, the other is that the
build might not use the ieee standard. I don't have a feel for if it is best to
enforce ieee in the file or do as per endianness and save as native then
convert during reading. In this case I lean slightly towards always using ieee.
Finally I think that it will be easier to develop and more user friendly to put
all this functionality into a handful of api calls, rather than as a separate
driver and utility. In fact if we add an input file command parameter to the
current interface, then most of the work is done.
These are just my thoughts on the issue as I am thinking about them and all are
up for discussion.
Phil
-----Original Message-----
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Sent: 09/01/2015 20:59
To: "Andrew Ross" <andrewr...@users.sourceforge.net>
Cc: "Phil Rosenberg" <p.d.rosenb...@gmail.com>;
"plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Subject: Re: [Plplot-devel] Fwd: metafiles
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
