John Hunter wrote:
> On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <[EMAIL PROTECTED]> wrote:
> 
>> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
>> _print_ps()):
>>
>>        self.figure.set_dpi(72) # Override the dpi kwarg
>>        dpi = kwargs.get("dpi", 72)
>>
>> The problem here is that while it sets the figure dpi here to 72, it's using
>> the dpi that's passed in down the chain.  Since I don't give it a dpi
>> explicity, it grabs the default dpi from my matplotlibrc, which has it set
>> to 300 dpi.  So 300 is getting passed down into the chain and I believe the
>> drawing commands are using 300 dpi.  If I change the second line above to
>> dpi = 72, I get the proper results.
> 
> Yes, we definitely need to get this fixed before any release, but we
> need to be careful here.  I had forgotten that Nicholas Young had
> submitted a patch to make the ps backend respect higher resolutions
> for embedded images
> 
>   
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg00353.html
> 
> so we cannot simply revert this to 72.  I also see the problem you
> pointed out in the collections module too.  While I don't have a quick
> fix at hand, at least we are starting to converge onto where the
> problems lie. Note that in the collections module the
> IdentityTransform is  bit of a red herring in the set_transforms
> method, since the collection maintains a list of transforms in
> _transforms that incorporates a dpi a draw time so I don't thing the
> standard artist transform property is used.

Yeah, I figured it was more complex thatn that.  While the 
IdentityTransform() might be a bit of a red herring, the fact remains 
that changing the dpi still changes the size of the of the marker 
relative to the canvas in a scatter plot saved with backend_ps, which 
doesn't occur with the image backends (at least I tested for png).

>> 2) backend_ps._print_figure() uses the md5 module to create a temporary
>> filename.  This module is deprecated in python 2.5 and removed (I believe)
>> in 3.0, replaced by hashlib.  Is there any opposition to changing the direct
>> use of md5.md5() to using a try...except to import md5() from it's proper
>> place?
> 
> I wasn't aware of the deprecation so I don't have any strong opinion,
> except that it wold be better if you can find a non-deprecated
> equivalent which is python 2.4 and 2.5 compatible.

Therein lies the problem, 2.5 deprecated md5 in favor of hashlib, which 
was added in 2.5.  So the options are:

1)Do nothing now.  Go back and fix the problem when we get around to
   supporting 3.x.  md5 has officially been removed from SVN for python
   3.0.
2)Move completely over to hashlib, drop support for <2.5
3)try to import md5() from hashlib, if that fails fall back to importing
   md5() from the md5 module.

Option 2 is not really an option, so never mind it.  Option 1 is the 
status quo, and it just means we need to keep it in mind as one of the 
issues that will have to be handled later when we move to 3.x.  I just 
read that in 2.6, md5 will issue a DeprecationWarning.  That probably 
kicks us to option 3.

Option 3 isn't too bad. Both the md5 objects from hashlib and from the 
md5 module support the same API. Hashlib lacks a module level function 
new() which md5 has, but this is just an alternative to using a class 
constructor, so code that uses new() (backend_svg) is easily moved over 
to code that works for both.

I'll volunteer to do the ports, which will mostly consist of:

try:
     from hashlib import md5
except ImportError:
     from md5 import md5

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

-------------------------------------------------------------------------
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=/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Reply via email to