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

Reply via email to