John,
Thank you very much--that's a big help. Some time today or tomorrow I
will try to track down any remaining quiver problems. I suspect similar
dpi-related problems may lurk elsewhere as well.
Those lazy values worked pretty well!
One of the things that puzzles me is the following method of
FigureCanvasAgg in backend_agg:
def print_png(self, filename_or_obj, *args, **kwargs):
FigureCanvasAgg.draw(self)
renderer = self.get_renderer()
original_dpi = renderer.dpi
renderer.dpi = self.figure.dpi
if type(filename_or_obj) in (str, unicode):
filename_or_obj = open(filename_or_obj, 'w')
self.get_renderer()._renderer.write_png(filename_or_obj,
self.figure.dpi)
renderer.dpi = original_dpi
The FigureCanvasAgg.draw(self) command gets turned into
self.figure.draw(self.renderer), which is executed *before* the
renderer.dpi gets set to self.figure.dpi, so it seems like there is the
possibility of an inconsistency. I suspect there is no problem in
practice, but it is confusing.
Now that I look again, it looks like what is happening is that the
get_renderer call in FigureCanvasAgg.draw is setting the renderer dpi to
the figure dpi, as well as setting self.renderer, in which case most of
the code in print_png seems to be superfluous.
Mostly unrelated question: is there any point in keeping
backend_agg2.py, or at least keeping it in the backends directory?
Maybe it is time to move that and backend_emf.py (and maybe others) to
some sort of cold storage, in case someone is inspired later to
resurrect them.
Eric
John Hunter wrote:
> On Sat, Apr 26, 2008 at 2:04 PM, Eric Firing <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
