On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
> 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. I just committed a fix here -- I renamed the renderer dpi instance to imagedpi to avoid confusion, and modified the various places in the artist code (collections, text) which were using renderer.dpi (they now use figure.dpi). Right now the only backend that was using the image magnification was backend ps. > 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. Yes, certainly points or some other physical dimension is the right way to specify pads. Where in the code are dots/pixels used? JDH ------------------------------------------------------------------------- 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
