On Saturday, January 10, 2015 at 13:57:16 (-0600) Maurice LeBrun writes:
> Design issues include:
> - The physical device coordinate space was a limiting factor, say for later
> zooms.
> - Ditto for the physical device API. A metafile/renderer built at a higher
> level would've had more ver
In my experience, you will definitely need file versioning. Won't be used
that often but essential for backward compatibility.
The original plmeta/plrender also had a nifty way to seek to a given page in
the file, seek forward/backward N pages, etc. Unfortunately it meant backing
up and filling
>> It wasn't clear from Phil's summary that he was going to use plbuf
code, but I hope he does.
yes that certainly was my intention
>> I'm not clear on the need to prefix the commands with the size
A couple of examples where this might be useful - lets say we find a bug
and it turns out that whe
On 2015-01-12 11:19-0500 Jim Dishaw wrote:
> I can make the changes [to plbuf] described by Phil. Should I pull the
> current released version from the repository?
Hi Jim:
It wasn't clear from Phil's summary that he was going to use plbuf
code, but I hope he does. If so, and you want to help w
On 2015-01-12 15:10- Phil Rosenberg wrote:
> Does this sound sensible?
Yes. Go for it.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with th
With the the changes to plbuf that need to be made to implement these features,
should the old code that was left in (the ifdef BUFFERED_FILE blocks) be
removed? The only time it is useful is on low memory machines that have the
ability to perform file I/O.
I'm not clear on the need to prefix
Okay then, so from all the various discussions I get the impression that
the consensus is
1) The easiest way to get the buffer into/out of PLplot would be to add a
command line option (e.g. -mfo filename and mfi filename) and have plplot
core code pick this up and write to/from it. this requires no
