On 2008-10-23 23:28-0400 Hazen Babcock wrote:

>
> On Oct 23, 2008, at 6:41 PM, Hezekiah M. Carty wrote:
>
>> On Thu, Oct 23, 2008 at 5:22 PM, Hezekiah M. Carty
>> <[EMAIL PROTECTED]> wrote:
>>> I have run across a problem using the extcairo driver and multiple,
>>> differently dimensioned plots.  The attached C program
>>> ext-cairo-test-problem.c is a modified version of
>>> examples/c/ext-cairo-test.c from the PLplot source tree and
>>> illustrates the problem I am having.
>>
>> Apparently this is not restricted to the extcairo driver, but instead
>> affects all Cairo plotting devices.  Another test using pscairo +
>> pngcairo shows the same issue.  The attached OCaml code illustrates a
>> similar problem with a misplaced plotted point at the last call to
>> plploin.
>
> The problem is here:
>
> static PLFLT downscale = 0.;
>
> This should be stored separately as part of each plot stream rather
> than being a single static global variable.

Hi Hazen,

The problem occurs in svg.c as well, and there may be others.

When I surveyed the devices recently in preparation for my scaling work
for svg.c, I found virtually all of them scale
(for obvious reasons) between internal PLplot (16-bit)
coordinates and device coordinates.  Just look for PIXELS_X somewhere in
the various device-driver source codes, i.e.,

[EMAIL PROTECTED]> grep -l PIXELS_X *
cairo.c
cgm.c
gd.c
null.c
pbm.c
plmeta.c
svg.c
tk.c
tkwin.c
wingcc.c
xwin.c

where PIXELS_X-1 = 32767 = maximum value of internal (virtual)
PLplot coordinates.  This may not be a complete list since the scaling
implementation may be done differently for devices not on this list.

When I did my scaling work for svg.c, I followed what was done in cairo.c so
the storage problem you found for cairo must also occur for svg.c as well. I
am not sure about the rest of the above list. For example, gd.c stores the
scaling factor in a device-specific struct, and I haven't followed the code
well enough to know whether separate versions of the struct are set up for
each stream or not.  Anyhow, I encourage you do a quick general survey to
find which devices have the scale storage problems for multiple streams and
which are okay.

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to