Can I suggest a script which runs all the standard examples, saves as 
plmeta files, then re-renders using the psc driver. It would be 
illuminating to compare with the direct psc driver and should also
highlight any missing API elements in the buffering. 

I'll see if I can knock something together.

Andrew

Note Maurice's comments about not completely reproducing the original 
device, but again it would be good to quantify that.

On Tue, Jan 13, 2015 at 03:48:52PM +0000, Phil Rosenberg wrote:
> Jim and others
> A gotcha that I just found doing unrelated stuff (actual work!) is that
> calls to plscmap0and plscmap0n are not saved to the buffer, but calls to
> plcol0 are saved to the buffer using the index it is called by. I found the
> bug because I was changing the colour map part way through plotting and
> getting odd colours on redraws. I guess plcolmap1 is probably similar.
> 
> I have a feeling that we might find a number of these type of problems
> along the way.
> 
> Phil
> 
> On 13 January 2015 at 05:42, Maurice LeBrun <m...@brownwolf.org> wrote:
> 
> > 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 versatility.
> >
> > Given all the recent discussion, I wanted to underscore the latter as
> > perhaps
> > the most irksome feature of the original plmeta/plrender paradigm.  Saving
> > the
> > plot data at the device level means that you can only recover the original
> > plot device output if it matches exactly the resolution of the metafile
> > "device".  So using the plot buffer, with perhaps limited extensions to
> > change
> > the things you can do to modify the output (e.g. affecting color palette),
> > sounds reasonable.  The ability to take a .plm file and render it after the
> > fact to any device was hugely useful but the fact that it was not
> > guaranteed
> > to match the output of the original device repeatedly caused us to pull our
> > hair out.
> >
> > --
> > Maurice LeBrun
> >

> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet

> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to