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 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'm trying to figure out how to eliminate the extra pen color
> command, but I'm not sure if I will be able.
>
> Eliminating this extra pen color noise from the diff is really
> important since it allows you to use cmp (with the first few bytes
> ignored to remove the time stamp from the comparison of PostScript
> results) as a diagnostic tool. Therefore, I hope you find the
> solution for this issue since that will allow us to check the plmeta
> capability on all standard examples as part of the test_diff_psc
> target (and the test_diff_svg target once we get to implementing that
> post release).
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().
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.
------------------------------------------------------------------------------
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
