matplotlib-devel Mailing List for matplotlib

On 9/21/06, Boyd Waters <bw...@nr...> wrote:
>
> On Sep 21, 2006, at 1:52 PM, Charlie Moad wrote:
>
> > At what point should we push another minor release for py2.5? or
> > should we at all?
>
> FWIW, I have matplotlib built against Python 2.5 on my Mac with the
> patches I posted in August.
> http://www.mail-archive.com/mat...@li.../
> msg00293.html
The problems addressed by those patches have been fixed. Win32, linux
and osx all compile fine now.
Thanks,

On Sep 21, 2006, at 1:52 PM, Charlie Moad wrote:
> At what point should we push another minor release for py2.5? or
> should we at all?
FWIW, I have matplotlib built against Python 2.5 on my Mac with the 
patches I posted in August.
http://www.mail-archive.com/mat...@li.../ 
msg00293.html
Not sure if that helps...
- boyd
Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
http://www.aoc.nrao.edu

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> At what point should we push another minor release
 Charlie> for py2.5? or should we at all? I am able to compile and
 Charlie> run the latest in svn on all 3 major platforms. The only
 Charlie> missing component is pygtk for windows. 0.87.5 is not
 Charlie> py2.5 compatible in many ways. Just thought I would
 Charlie> throw it out there.
I've CCd Cedric Gustin, who maintains pygtk for win32. Cedric, do you
plan to push out a python2.5 version in the near future? If so, we
can hold up the mpl release which uses some pygtk extension code in
building. If not, we can go ahead with the release w/o gtk support,
since this is not a common backend on windows.
JDH

 At what point should we push another minor release for py2.5? or
should we at all? I am able to compile and run the latest in svn on
all 3 major platforms. The only missing component is pygtk for
windows. 0.87.5 is not py2.5 compatible in many ways. Just thought I
would throw it out there.
Charlie

Hi Nicholas,
Thank you for the submission. I won't have time to look at this for a while (I 
will be out of town and out of email contact for a couple of weeks.) Maybe 
one of the other developers will have some time to consider your patch, 
otherwise, I'll have a look when I get back. Would you post it to the bug 
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. 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