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