Hi Alan and Jim
One other implementation option I just thought of - would a command line
option be a relatively easy way to indicate that a metafile must
be written? Then the core library could do this transparently
whatever driver is being used and basically the only code needed would be
an if statement somewhere in plbuff.c. A similar command line option to
read in a file would give a nice symmetry too. Any thoughts?
Alan - a question about git procedure. We are going to end up in a
situation here where my wxWidget branch that I've already begun is going to
require access to changes made on other branches. I think the only way to
do this is to merge the master branch into my project branch. Does this go
against our git policy and will the git hooks on the server accept it?
One more question about release dates etc. The wxWidget changes are going
to end up quite extensive. I have already rewritten the wxPLplotWindow
class (removing a diamond inheritance problem) and my intention is to also
remove the Agg backend, the freetype font option and possibly the
wxGraphicsContext backend in favour of the wxGCDC (a wxDC wrapper around
wxGraphicsContext) which will leave us with only one wxWidgets backend
option to maintain. Of course this is a major change to the public API for
the wxWidget driver, it will also require WxWidgets 3.0 (the current driver
requires 2.8), but given that Ubuntu 14.04 include 3.0 in the repos I
assume this won't be much of a problem? My main question is do we want to
depreciate the current API but leave it untouched for this release to give
users some warning or should we just press ahead?
Phil
On 10 January 2015 at 12:22, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:
> On 2015-01-09 22:15-0000 Phil Rosenberg wrote:
>
> [...] I also to some extent agree with this [SVG approach, but] a
>>
> binary format is more compact and faster to read and write. So there
> are some advantages to our own [binary] format, the question is whether the
> effort is worth the benefits.
>
> To Phil and Hazen:
>
> I suspect the answer to Phil's question above is yes, provided you can
> reuse already existing binary format functionality such as plbuf. The
> principal reason why I lean toward binary format compared to SVG
> format is because of binary format's intrinsically more compact nature
> which Phil mentioned above. This advantage not only includes the
> intrinsically more compact number representation available in binary
> format but also because binary format doesn't require the substantial
> size overhead you have with SVG format due to the necessity for that
> format of using tag and attribute names throughout the file in order
> for that file to be parsable as the SVG schema of XML.
>
> Of course, this overall size factor doesn't matter too much for small
> plmeta files or if you keep your large plmeta files on a single
> computer (since disk space is really cheap). But bandwidth is
> relatively expensive so as soon as you attempt to transmit substantial
> plmeta files between computers, then the plmeta format with the
> smallest size footprint has a substantial advantage.
>
> That said, you could mitigate the size disadvantage of SVG by using
> compression whenever you transmit it from one computer to another. So
> to my mind that possibility and the universal nature of SVG format
> partially overcome the advantage of the intrinsic (i.e., no
> compression/decompression required) compact advantage of binary format
> that can be implemented in a natural and straightforward way with
> plbuf capability. Which is the reason why I said "lean toward binary
> format" above rather then making a stronger statement in favor of
> binary format. In fact, since this appears to be a pretty narrow
> margin in favor of binary format whichever of you decides to implement
> their preferred method first gets my vote. :-)
>
>
> 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
