On Mar 4, 2015, at 8:50 PM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca> wrote:
> 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. > I got the symbol issue sorted out with some changes to EscText so that the correct information can be stored in the metafile. I have not nailed down the exact problem that is causing the dashed line grid in plbox() to be different. My guess is that I will need to implement a solution like the one you propose. ------------------------------------------------------------------------------ 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
