matplotlib-devel Mailing List for matplotlib

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

Eric Firing wrote:
> John,
> 
> I made some more changes in quiver, and I think they will ensure that 
> dpi changes are handled correctly as far as arrows are concerned, both 
> in the plot and in the key.
> 
> There is still a problem with the key label, and it can be seen clearly 
> in the attached slight modification of quiver_demo.py. There are 
> actually two visible problems:
> 
> 1) The hline generated by frac is too long with dpi=50.
> 
> 2) The positioning and sizing of the key bbox are also dpi-dependent, as 
> I verified by using your bbox-display trick.
The plot thickens. The postscript backend is completely confused by the 
quiver plot. Try the attached example.
pdf seems OK.
Eric

John,
I made some more changes in quiver, and I think they will ensure that 
dpi changes are handled correctly as far as arrows are concerned, both 
in the plot and in the key.
There is still a problem with the key label, and it can be seen clearly 
 in the attached slight modification of quiver_demo.py. There are 
actually two visible problems:
1) The hline generated by frac is too long with dpi=50.
2) The positioning and sizing of the key bbox are also dpi-dependent, as 
I verified by using your bbox-display trick.
I went hunting through text.py, mathtext.py, backend_bases, and 
backend_agg without figuring out where the problem is. The right dpi 
seems to be getting used at mathtext parsing time. Maybe it is not 
actually getting propagated all the way into the code that gets the font 
metrics. I did not try to trace it that far.
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.
Eric
John Hunter wrote:
> On Sat, Apr 26, 2008 at 2:04 PM, Eric Firing <ef...@ha...> wrote:
> 
>> The attached script, run on svn mpl, illustrates a positioning problem: note
>> that the subplot titles are badly positioned in the 50 dpi version. I
>> believe that changing from 150 to 50 dpi should yield a perfect scaling of
>> everything in the plot, but it doesn't. There is a similar problem with a
>> quiver key positioned outside the axes frame, but I don't have a trivial
>> example yet; I am hoping that whatever solves the title positioning problem
>> will take care of that also. If not, I will make a simple example and we
>> can attack it separately.
> 
> There were two problems with title positioning. The first was that
> the title offset transformation was hardcoded in pixels and not dpi,
> and the second was that is was not getting notifed when the figure dpi
> was changed. I changed the offset to read:
> 
> self.titleOffsetTrans = mtransforms.Affine2D().translate(
> 0.0, 5.0*self.figure.dpi/72.)
> 
> and added a callbacks registry to the figure instance so that
> observers could be notified when dpi was changed (dpi used to be a
> lazy value on the maintenance branch but is a plain-ol-value on the
> trunk).
> 
> def on_dpi_change(fig):
> self.titleOffsetTrans.clear().translate(
> 0.0, 5.0*fig.dpi/72.)
> 
> self.figure.callbacks.connect('dpi_changed', on_dpi_change)
> 
> It looks like the problem in the quiver code is that the "labelsep"
> property reads the dpi when the QuiverKey is intiitalized but does not
> get notified on dpi change. I added a callback there too so you
> should test to see if this helps. The dpi setting is also referenced
> in the _set_transform method. Since you are more familiar with the
> quiver code that I am, and this hint may point you in the right
> direction, I'll let you take a look at that and see if a callback is
> needed.
> 
> On a related note, one trick I use when debugging text layout problems
> is to turn on the "bbox". If the bbox is right but the text is in the
> wrong place, you know it is in the layout. If the bbox is in the
> wrong place, you know the problem is in the font metrics:
> 
> boxprops = dict(facecolor='red')
> ax1.set_title('Top Plot', bbox=boxprops)
> 
> JDH