Hi Alan, Thanks for your analysis, it was very interesting. Perhaps if I were to take an extended look at that 20-yr-old fix I might be able to dredge up some insights. OTOH, the ps driver was not my creation and I never felt truly comfortable modifying it. I basically just hacked it as needed to get the desired printable output. In other words, you're on your own, good luck. :)
Maurice On Thursday, October 23, 2014 at 22:44:52 (-0700) Alan W. Irwin writes: > 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
