On 2015-02-06 15:15-0500 Jim Dishaw wrote:
> On Feb 6, 2015, at 2:40 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote:
>
>> On 2015-02-06 08:36-0500 Jim Dishaw wrote:
>>
>>> I was able to get nearly identical outputs using psc with a replot
>> of the plot buffer. The only differences were the time stamp in the
>> header and an additional pen color command that doesn't affect
>> anything.
>>
>> Hi Jim:
>>
>> That sounds like an extremely encouraging result. Did you test that
>> for all of our standard examples or just a few of them? I also suggest
>> you do the equivalent test with -dev svg since that device has
>> essentially full PLplot capability while -dev psc is missing a lot
>> and therefore does not provide as stringent a test.
>>
> I implemented one test derived from example 1 because it exercised a
good set of features. I would need to create modified versions of
each example, which I am not sure is a good use of time nor necessary.
I think I need to clarify what I meant which would require
no change to current standard examples.
For the existing unchanged C examples and current plmeta device you
should be able to do something like the following:
examples/c/x??c -dev plmeta -o <output plmeta file>
plrender -i filename -dev psc -o <output psc file result>
Then compare that <output psc file> result with the result obtained
directly by
examples/c/x??c -dev psc
And similarly for -dev svg.
I assume that the syntax won't be quite the same once the new plmeta
capabilities land on git master, but the same fundamental tests
(of comparing PostScript or SVG results derived via plmeta capabilities
with directly derived results) should be possible for all standard
examples. I also emphasize this is something I will likely
implement, but I will likely put this off until post release because
there are so many calls on my time at the moment.
> I would rather have one (or maybe two) program that exercises the set
of commands and tests for identified bugs that have been fixed (to
prevent regressions).
I agree such a single special test is a good idea because there is no
guarantee that the combination of all our standard examples and a
particular file device driver exercise all plbuf possibilities.
However, likely post-release I will implement the above plmeta test
in addition to supplment your single special test.
> [...]I know where the extra plot color is coming from, I'm not sure of
the best way to fix it. I put the current pen color into the buffer
when the buffer is initialized to ensure the redraw has the correct
colors. The underlying issue is that the initial color is never set
via a plplot command, it happens internally. For example, in
pl_bop_ps() the initial pen color is set via:
>
> {
> r = ( (PLFLT) pls->cmap0[0].r ) / 255.;
> g = ( (PLFLT) pls->cmap0[0].g ) / 255.;
> b = ( (PLFLT) pls->cmap0[0].b ) / 255.;
>
> fprintf( OF, "B %.4f %.4f %.4f C F\n", r, g, b );
> }
>
> I have not checked every driver to see how the initial color is
handled. Depending on what I find, there are a couple of fixes. The
fix might be as simple as removing the initial color from plbuf. A
more serious fix is to move setting the initial color from the device
specific bop function to the plcore bop function plP_bop().
We do deliberately allow a lot of freedom to device developers to
implement various solutions to common problems in a variety of ways,
but once the alternatives are explored for various devices it is
always a good idea to replace the variety of ways each device driver
deals with an issue with the best of all methods implemented in the
core. So if your look at every device driver convinces you we are
ready for such a change in the way the initial colors are set, then I
would certainly encourage you to go ahead and make that change.
>
> I am using psc for now because I can actually read it to find the problems.
> Having it use the svg driver is a trivial change.
>
>>
>> Anyhow, I do hope to see such a patch series (including at least one
>> plbuf test) from you in time (i.e., before the soft freeze date two
>> weeks from now on February 21st) so that we can incorporate it into
>> this forthcoming release.
>>
>
> My plan is to have a set of patches by next friday.
That would be great since two weeks before the release date and one
week before the soft freeze date makes it much more comfortable for me
to throughly test your changes (and everyone else's changes) before
release.
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
