To Maurice and Andrew: I think you will be interested both in the history of this issue and also how I resolved it. If either of you think I screwed up this fix of Maurice's (1994) fix, please let me know!
Basically Maurice's fix emitted M commands for _every_ state change other than PLSTATE_WIDTH. The complete list of those state changes (as far as I know) other than PLSTATE_WIDTH is PLSTATE_FILL, PLSTATE_COLOR[01], and PLSTATE_CMAP[01] and evidentally one or more of those which are normally no-ops for the ps device (i.e., PLSTATE_FILL and PLSTATE_CMAP[01]) have been triggered by rounding differences with the result that isolated M commands are being emitted for one type of rounding compared to another. My fix essentially returned the M command emitting code back to what it was like prior to Maurice's fix but with the undefined variable issue fixed; the M commands are now only issued after a C command, i.e., only for case PLSTATE_COLOR[01] and only if the relevant variables for the M command are defined. Andrew's psttf device driver code is partially based on the ps device driver code and evidentially Maurice's fix propagated to the psttf device driver so I had to fix that as well. I still have no idea why the C command must be followed by an M command for PostScrit. That decision was made before 1994. Hopefully, Maurice or Andrew will be able to comment on the reason for this. For further details about the current fix and Maurice's fix see <http://sourceforge.net/p/plplot/plplot/ci/3028bea51568a023dcf3612a664a8a4345e91b14> and <http://sourceforge.net/p/plplot/plplot/ci/07eab71b70249ac03a0f89db4061583d968f7365>. Note the current fix likely does not get rid of all causes of extreme sensitivity of the psc device results to rounding issues, but I do recall a number of such issues in the past that also involved extra M PostScript commands being emitted by one language compared to another. Therefore, I believe this current fix will at least get rid of a substantial subset of such issues, and it certainly gets rid of that issue for the Python/C special test comparison of the new example 8 results. Tomorrow after removing some special testing hacks and throughly testing the final new Python example 8 against the repository version of the C code, you should see a commit from me of that new Python code, and I hope my further planned changes to example 8 for Octave and Java are a lot less interesting than they have been for the Python case! 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
