matplotlib-devel Mailing List for matplotlib

Hi Nicholas,
Thank you for the submission. I won't have time to look at this for a while=
 (I=20
will be out of town and out of email contact for a couple of weeks.) Maybe=
=20
one of the other developers will have some time to consider your patch,=20
otherwise, I'll have a look when I get back. Would you post it to the bug=20
tracker at the sourceforge site?
Darren
On Wednesday 20 September 2006 12:34, Nicholas Young wrote:
> Hi,
>
> I sent this message to the list this time yesterday and it doesn't seem
> to have either arrived or bounced - so I'm trying again.
>
> I've written a patch (attached) to allow the PS backend to respect the
> dpi that's given to the FigureCanvasPS on initialisation when saving
> images. =A0The solution I came with to do this isn't the nicest, but I
> couldn't see any significantly different way to do it without changing
> the rendering process for images.
>
> What I've done is add a get_image_magnification method to the default
> backend with a default return value of 1.0. =A0This magnification factor
> is then taken by the draw method of the figure, axes or image and passed
> as a keyword argument to the make_image method of the image where it
> used to scale the widthDisplay and heightDisplay returned from the
> bounding box. =A0(I also changed the self.make_image(False) call in
> Image.write_png to self.make_image() as I'm pretty sure that's what was
> meant to be - and if I hadn't the introduction of my new keyword
> argument would have resulted in a zero size image.)
>
> By returning a magnification of dpi/72.0, the PS backend is able to
> instruct the image instances to create larger images which it then
> scales by an appropriate value on output to give the requested dpi.
>
> This patch, or something like it, is vital for me at the moment because
> the low 72 dpi output used by matplotlib at the moment gives rise to
> some fairly significant distortion to my results. =A0I imagine others will
> come across the same problem.
>
> I hope this patch is useful,
> Nicholas Young

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> would be nice. Or, if I write something like this myself,
 Manuel> is there any chance to add this to matplotlib ?
certainly.

Hi,
when I try to plot a line that contains circles, I obtain this error:
/usr/lib/python2.4/site-packages/matplotlib/lines.py in
_draw_circle(self, renderer, gc, xt, yt, point)
 616 for (x,y) in zip(xt, yt):
 617 renderer.draw_arc(gc, rgbFace,
--> 618 x, y, w, w, 0.0, 360.0, 0.0)
TypeError: draw_arc() takes exactly 9 arguments (10 given)
I guess there is an extra '0.0' argument.
I found this error in matplotlib-0.87.5 (using gtk backend).
Regards
Marco 
-- 
"I videogiochi non influenzano i bambini. Voglio dire, se Pac-Man avesse
influenzato la nostra generazione, staremmo tutti saltando in sale
scure, masticando pillole magiche e ascoltando musica elettronica
ripetitiva."
"Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we were all jumping in dark rooms, chomping pills and
listening to electronic repeating music."
Kristian Wilson, Nintendo Inc. 1989

Hi,
first of all "scatter_custom_symbol.py" is great ! I really like this.
But...
May I express some idea/suggestions concerning custom symbols:
I came from supermongo to matplotlib. And I liked the way you could
define symbols in supermongo:
 PTYPE n s
where "s" gives the style of the symbol:
 s = 0 open
 s = 1 skeletal; all vectices are connected to the centre
 s = 2 starred
 s = 3 solid
and "n" is a the number of sides the polygon has. For example:
 PTYPE 4 0
creates open squares whereas
 PTYPE 4 1
creatse X-like symbol. Btw. I like those unfilled symbols because you
can plot lots of them without overcrowding your figure.
It is also possible to use
 PTYPE 0 0
which draws the smalles possible dots on a device, i.e. a single pixel
on a screen; this can also be very helpful if you want to plot lots of
datapoints.
One can also use an angle argument, e.g. transform a 'X' symbol to an
'+' symbol by rotation it about 45 degrees.
Is it possible to integrate a similar way to create custom symbols in
matplotlib? Probably something like
 verts = PolyMarker(n=4,s='open',angle=0)
would be nice. Or, if I write something like this myself, is there any
chance to add this to matplotlib ?
Manuel

It builds now. We still have to wait on a useable numpy for python2.5
and pygtk for windows/py2.5. All the other components are there or we
can build.
On 9/20/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> This came up on the dev list yesterday and we tried with
> Charlie> swig-1.3.29, which is the latest listed release on SF.
> Charlie> The link you provided shows this was indeed fixed after
> Charlie> the 1.3.29 release. Jon, can we give bleeding edge swig
> Charlie> a try?
>
> OK, bleeding edge SWIG versions of the agg wrappers are in svn.
>
> Good luck!
>
> JDH
>

Hi,
I sent this message to the list this time yesterday and it doesn't seem 
to have either arrived or bounced - so I'm trying again.
I've written a patch (attached) to allow the PS backend to respect the
dpi that's given to the FigureCanvasPS on initialisation when saving
images. The solution I came with to do this isn't the nicest, but I
couldn't see any significantly different way to do it without changing
the rendering process for images.
What I've done is add a get_image_magnification method to the default
backend with a default return value of 1.0. This magnification factor
is then taken by the draw method of the figure, axes or image and passed
as a keyword argument to the make_image method of the image where it
used to scale the widthDisplay and heightDisplay returned from the
bounding box. (I also changed the self.make_image(False) call in
Image.write_png to self.make_image() as I'm pretty sure that's what was
meant to be - and if I hadn't the introduction of my new keyword
argument would have resulted in a zero size image.)
By returning a magnification of dpi/72.0, the PS backend is able to
instruct the image instances to create larger images which it then
scales by an appropriate value on output to give the requested dpi.
This patch, or something like it, is vital for me at the moment because
the low 72 dpi output used by matplotlib at the moment gives rise to
some fairly significant distortion to my results. I imagine others will
come across the same problem.
I hope this patch is useful,
Nicholas Young