Eric Firing wrote: > Christopher Barker wrote: >> David Goldsmith wrote: >>> I feel like I must be missing something >> yup -- though it's an understandable miss... > > I think the longstanding separation between the figure.dpi and the > savefig.dpi is a continual gotcha that we can and should eliminate. > Savefig should use the figure dpi, so that what is saved corresponds to > what is on the screen, unless explicitly overridden. One way to reduce > the problem, with what I hope is an adequate level of backwards > compatibility, would be to have the savefig.dpi default to a special > flag setting that means "track the figure.dpi". For example, > savefig.dpi could be the string, 'screen', by default. This could still > be overridden by a numerical rcParams setting, or by the explicit dpi > kwarg setting in savefig() or print_figure(). > > There are still other highly confusing dpi things internally--such as a > renderer.dpi setting that is ignored during rendering. > > Comments?
+1 On your suggestion. I agree this is confusing at times. Unfortunately, I don't have any time to offer for code at this time. (Hopefully more time for MPL soon!) 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-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
