On Sun, Apr 27, 2008 at 3:14 AM, Eric Firing <ef...@ha...> wrote: > 1) The hline generated by frac is too long with dpi=50. The problem with the hline appears to be that the width of the line in the frac has a component that depends on the thickness thickness = state.font_output.get_underline_thickness( state.font, state.fontsize, state.dpi) width = max(num.width, den.width) + thickness * 10. and get_underline_thickness here is defaulting to 1.0 because of this max call in get_underline_thickness return max(1.0, cached_font.font.underline_thickness / 64.0 / fontsize * 10.0) Michael -- what is the role of these 10.0 scale factors, which is showing up in both the frac call and the get_underline_thickness? Is this something from Knuth, or is it a fudge factor that gets it mostly right? I suspect we will need something like width = max(num.width, den.width) + thickness * 10. * state.dpi/72. but with this change the frac bar looks a little too wide -- which is why I'm wondering if there is something magic about 10. or if another number might serve better. > Along the way, I found that in backend_bases, print_figure was doing what > appears to be a completely unnecessary draw operation after restoring the > original dpi, so I commented that out. This speeds up backend_driver.py agg > by a few percent. I think you are right here -- because we are creating a new FigureCanvas and hence a new renderer in the switch_backend call we do not need to redraw the original figure with the original facecolor, edgecolor and dpi params. In older versions of mpl, if memory serves correctly, calling savefig would reuse the same renderer so after the print to hardcopy we would redraw so the figure in the GUI window would look right. But I agree this looks superfluous in light of the current code which is creating a new canvas with each savefig. JDH