> On Mar 4, 2015, at 6:04 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> On 2015-03-04 02:41-0500 Jim Dishaw wrote: >> >> I have gotten things to the point where the differences are due to > round off error, the rendering of non-solid lines, and plot symbols > generated by commands that utilize plhrsh (i.e. plsym, plpoin, and > plpoin3). > > Thanks, Jim. Sounds like you have made a lot of progress. > >> Rendering non-solid lines I can't think of a simple solution to > this problem without a major change. As it currently stands, the end > user would need to look very closely to see any differences. It > really is a problem if you comparing output files. > >> Plot Symbol Issue >> With the current architecture, I can either store them as a text > string (if there is a unicode representation) or as rendered vectors. > However, if they are stored as a text string, there is no way to > distinguish points from the other strings. > > Of course, it is always true that if you store raw user input (as > opposed to some transformed result) in the plmeta file and then > plrender calls the relevant plplot routine with that raw user data, > then the direct and indirect result must be identical. So in all > cases I would try to work with raw user input rather than try anything > more complicated. For the plstring, plmtex, and plptex cases we > discussed before that raw user input was a null-terminated char array > that was accessible to plmeta via args.string. > > In the present case of symbols (where I assume the functions you are > referring to are plsym and plpoin), the raw input user data is the > integer code argument for each function. So for the special case of > the plmeta device can't you make the value of code accessible to the > plmeta device (and stored as part of the plmeta file) via a call to > plP_esc with unique op code near the start of plsym and plpoin? > > If you think that escape code trick should work as a way to transport > raw user input directly to plmeta to be stored in the plmeta file, can > you also use a similar trick to transport and store the relevant raw > user input data for the non-solid line case? >
That is my thought. My plan is to make some changes to the EscText structure that will enable plmeta to distinguish between plot symbols and text and get the original code. > 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
