On Mar 4, 2015, at 6:04 AM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote:
> > 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. > I modified the plP_text routine to always store the raw text in args.string. That change did not break any of the drivers and plmeta copied the text from that field. After my digging through the code and the new direction that I will take in plsym.c, that change might not be necessary. > 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 much trickier with the current architecture. The plmeta driver is at the same level as all the other drivers, which is after all the coordinate transformations. To do what you describe will take more work (more than I am comfortable doing this close to release). There are different approaches to implementing what you describe. One thought that I had was to restructure the interface to the drivers by expanding and unifying a "driver capabilities" structure. We sort have that now with a dev_unicode, dev_text, dev_hrshsym, hardware fills, etc. Basically, my thought is that a driver would be able to declare that it has a native capability to all the primitives (pattern fills, dashed lines, etc) and coordinate transformations. Then all PLplot would do for that driver is layout the plot. For less capable drivers, PLplot with render the missing features. I have not figured out how to handle clipping and difilt in this architecture. ------------------------------------------------------------------------------ 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
