On 2015-03-04 16:07-0500 Jim Dishaw wrote: > > On Mar 4, 2015, at 4:01 PM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote: > >>>> Regarding non-solid lines, are you referring to dashed lines? If so what >>>> is the issue? >> >>> The devices have different number of pixels, which results in a different >>> number of dashes. >> >> The plplot docs state that the dash sizes are specified in mm. They >> should therefore be saved in the buffer as mm and converted to device >> coordinates at render time using the current device dpi. At least that >> is how I would read the situation. >> >> Phil > > That is the crux of the problem. The plmeta device sits at the end of all > the coordinate transformation and there is no easy way to get at that > information.
Hi Jim: I think Phil is absolutely right, but so are you about the problem of communicating untransformed information to plmeta. However, as I have said before, to deal with that communication issue I think the solution is simply to add _just for NEW_METAFILE and when the device is plmeta_ (see #ifdef and if statement below) some calls to plP_esc to pass the required untransformed information to the plmeta device. You have previously rejected this solution as too intrusive close to release, but I don't think this solution is intrusive at all to the PLplot core since all you will see there would look like (note this is untested code) #ifdef NEW_METAFILE if( !strcmp(plsc->DevName, "plmeta") ) plP_esc(PLESC_META_CODE, &code); return; } #endif ... continue with plpoin or plsym. where there would be an option in CMake to define the C macro NEW_METAFILE if that is what the user desired, and you would #define various PLESC_META escape codes to handle all required situations where untransformed information needed to be communicated. So the above would be a complete no-op for the old plmeta/plrender, but for the new plrender this method would pass whatever untransformed information (such as the value of code) you need to plrender. Of course, this change is a bit disruptive to _new_ plmeta/plrender, but we don't intend to make new plmeta/plrender part of this release. So you are free to charge ahead on this (ASAP, please) without worrying about release issues, and if you have success on at least one platform, you have created a fine tool to test plbuf which would be immediately helpful for this release. 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