On 2015-03-02 02:01-0500 Jim Dishaw wrote: > Attached is a patch for testing, I don't recommend pushing it to master yet. It comes very close to rendering a metafile "identically" (modulo rounding differences). The main problem is that plot symbols are missing. I should be able to fix that on Monday.
Hi Jim: I have argued in my just previous post that no special processing of unicode or alt_unicode should be necessary at all by plmeta or plrender/plbuf code since the PLplot core library code and individual device code know how to do that special processing already. To make that argument more concrete, explore what happens if you test that hypothesis by setting pls->dev_unicode = 0 in plmeta.c for the NEW_METAFILE case. In that case the core stores a pointer to the raw (i.e. completely untransformed) input char array in args->string and the new plmeta code outputs that null-terminated char array to the plmeta file. That is the correct thing to do in all cases if you agree with my further assumption below. For the above to work those raw char arrays also must receive no special plrender or plbuf processing. Instead, they should just be sent off to the plcore using a plP_text call which then should initiate normal text processing for whichever device has been specified by the user using the -dev option for plrender. So I assume such a plP_text should be possible based on the data stored in the plmeta file. If you agree with that assumption, then it follows this method should drastically simplify text handling for plmeta and plrender modes (since in the plmeta case you can drop all unicode and alt_unicode code and similarly for plrender/plbuf, and I hope you would be willing to modify your patch accordingly. > I was having problems with the xcairo driver after resizing the plot window. Is anyone else having that problem? No problems here except for the long-standing one that resizing the xcairo GUI leaves the actual plot the same size with either a larger background (if the resize is to larger sizes) or clipped region of the original plot (if the resize is to smaller sizes). So resizing basically sucks with xcairo, but I assume it will be fine if we can move that xcairo resizing code to a plbuf-based approach. 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
