> On Mar 2, 2015, at 4:55 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > >> 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.
Fortunately what you describe is almost how things are implemented. I can't rely on null terminated strings because if real Unicode strings are passed, they can can contain null bytes. That will require the use of string lengths to make metafiles agnostic. > >> 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. > I will take a look at xcairo and see if I can fix it. It is a good test case for the work I'm doing with the metafiles. ------------------------------------------------------------------------------ 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
