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.
I was alluding to this in my earlier rants about scatter and
PolyCollection. The mechanism of the list of transforms is fine, but
the kwarg name and API are bad, and additional comments are needed. I
was going to hold off until after the release, but maybe I should go
ahead and try to improve this, in a 100% backwards-compatible way, as
soon as I can get to it.
>
>> 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.
If it is a temporary file, why not use one of the functions in the
tempfile module? I have not looked at the code to see whether one of
them would be appropriate, but it seems odd to have to use some other
module.
Eric
-------------------------------------------------------------------------
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
