Ryan May wrote:
> John Hunter wrote:
>> On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>>
>>> What else is confusing is how that relates to DPI. When I change the
>>> figure's dpi, using set_dpi, (and redraw), I get physically *bigger*
>>> barbs.
>>> To me, if I'm actually specifying pixels, there's no way that they
>>> should
>>> get bigger when I change the DPI.
>>
>> When you increase the dpi, the canvas gets bigger (inches*dpi equals
>> canvas size in pixels). If you are drawing in pixels, and not
>> scaling, the barbs should look smaller, since they are a smaller
>> proportion of the canvas size. So if this explanation is right, the
>> barbs will look smaller with larger dpi.
>>
>>> Then I also can't figure out what the PS backend is doing. If PS is
>>> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any
>>> effect?
>>
>> ps should be unaffected, but dpi dependent backends will. By setting
>> the dpi to be 72, it should make the *other* backend look like the ps
>> backend and the ps backend should be unaffected.
>
> 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.
>
> So what's the proper fix in this case, or is this it? It'd probably be
> good to get this in for a release.
This is the kind of thing I would want to look at and test *very*
carefully, or know that someone like John or Mike has done so--which
perhaps one of them can do quickly. I have looked at this dpi business
with puzzlement before; I don't have it all straight in my head; and I
would need a chunk of time to review it, which I might get in the next
day or so, but can't guarantee.
It would be nice to not only fix the bug, if such there is, but also
clarify the whole mess for all backends, maybe with some additional
variable names. I think that for pixel backends, there is a single dpi
per rendered figure, so the situation is simple; but for vector backends
(ps, pdf, svg), there are fundamentally two: one that is used for
translating dots to inches as measures of length, and another that sets
the dpi (hence resolution, not size) for raster images that are
contained within the figure. (I don't know where the cairo backend
sits, since it can render either raster or vector file types.)
Another aspect of the problem is that at least for use with vector
backends, specifying lengths in dots is unnatural; and it seems to me
like something to be avoided when possible even for raster backends. I
would argue that pad variables should be in physical or relative units,
where relative could mean relative to the figure size, or to a font em,
for example. Specifying lengths in dots is just asking for trouble
except when the plot is not intended to be scaled; when making a small
png for the web, precise control via lengths in dots may be helpful.
Eric
>
> There were a couple other things I noticed:
>
> 1) The canvas.print_figure() method goes to the trouble of saving the
> facecolor and edgecolor before resetting them to what's passed in for
> purposes of writing out the image. Then later,
> backend_ps._print_figure() does the same thing a few calls down the
> stack. Is one of these redundant, or is there a reason for the
> duplication?
>
> 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?
>
> Ryan
>
-------------------------------------------------------------------------
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
