Eric Firing wrote: > I think the longstanding separation between the figure.dpi and the > savefig.dpi is a continual gotcha that we can and should eliminate.
+1 I've never understood the separation -- why wouldn't it default to the figure.dpi -- it could always be overridden by the keyword arg anyway. > 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. the thing is, this problem occurs even if there is no screen -- i.e. with just the Agg back-en, maybe "figure" or "preserve" or something? > This could still > be overridden by a numerical rcParams setting, or by the explicit dpi > kwarg setting in savefig() or print_figure(). well, either the default behavior is changed, or it's not. Are you proposing that the default rcParams setting be "screen" (or whatever), in which case it could be returned to the old behavior (set to 100?) with a change, if the user so chooses? If so, I think I'd not bother. if the default change,s let folks learn to add a dpi keyword arg in their code. If you were thinking that the default rcParam would be the current behavior, then I'm not sure we're removing the "gotcha". I suppose another option would be to make the dpi argument non-optional -- then everyone would KNOW that needed to specify the dpi. Ugly, but no ones code would break without them knowing it broke. Does MPL have a deprecation warning policy? > There are still other highly confusing dpi things internally--such as a > renderer.dpi setting that is ignored during rendering. I'm not familiar with this one, but I think it does make sense to address these all at once. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
