matplotlib-devel Mailing List for matplotlib

On Sat, Jul 26, 2008 at 5:26 PM, Paul Kienzle <pki...@gm...> wrote:

> I went through all the demos in pylab_examples to make sure that
> the artist.contains() method would return true when the mouse
> is on the object.  I fixed a number of problems caused by the
> new transforms code (collections, lines and images were not
> detected).  A few issues remain, but they are not show stoppers.

Thanks for the comprehensive tests.  I've had a minute to work on a
couple of these before I have to run out
>
> Broken examples:
>
>  barcode_demo

fixed -- added to backend_driver

> image_interp, etc: wx doesn't implement draw_image

I'm not too concerned about wx, and am somewhat inclined to pull it,
especially now that we have support for external backends so those who
need it can use it.    I won't pull it for this cycle.  Anyone who
loves wx, now is the time to step up andstart adding support for
missing features like images and mathtext.

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered.  So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called.  I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first.  *please test*.

>  dannys_example: wx doesn't implement draw_tex

not concerned here about wx, but we need to make sure wxagg is working
here (confirmed)

>  font_table_ttf: list index out of range

punting for now

>  geo_demo: invalid value in projections.geo for x = ... / sinc_alpha

added to the sf bug tracker, assigned to Michael.  Added to
backend_driver (failing now)

>  multi_image: AxesImage has no attribute add_observer

fixed in svn to use the new callbacks API for scalar mappables.  Added
to backend_driver

OK, that's all I have time for now.  I'll take a look at the others
later.  Thanks a lot

JDH

>  stix_fonts_demo: error
>    UnicodeDecodeError: 'rawunicodeescape' codec can't decode
>    bytes in position 39-0: \Uxxxxxxxx out of range
>  symlog_demo: rendering causes the following error
>    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
> line 1072, in transform_point
>      assert len(point) == self.input_dims
>  running reindent.py causes lots of changes
>
> Hit test issues:
>
>  barb_demo: detecting filled areas but not lines
>  dashtick: not detecting dash ticks, except by tick
>  date_demo2: rotated text uses bounding box rather than rotated rectangle
>  newscalarformatter_demo: axis offset label not detected
>  quiver_demo: 1 m/s arrow legend not detected
>  scatter_star_poly: plus and star not detected
>
> If you want to turn on hit testing for a plot, use:
>
>    gcf().canvas.mpl_connect("motion_notify_event",
>                             gcf().canvas.onHilite)
>
>
> - Paul
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Andrew Straw wrote:
> Hi all,
> 
> I've added some functionality to my copy hexbin, and I thought I'd
> bounce it off folks (esp. Michael) to see if it seems like a good idea
> to add it to MPL.
> 
> Here's the beginning of the docstring of the new version. What I've
> added is the optional argument "C" -- inspired by scatter's "c" argument.
> 
>> call signature::
>>
>>   hexbin(x, y, C = None, gridsize = 100, bins = None,
>>          xscale = 'linear', yscale = 'linear',
>>          cmap=None, norm=None, vmin=None, vmax=None,
>>          alpha=1.0, linewidths=None, edgecolors='none'
>>          reduce_C_function = np.mean,
>>          **kwargs)
>>
>> Make a hexagonal binning plot of *x* versus *y*, where *x*,
>> *y* are 1-D sequences of the same length, *N*. If *C* is None
>> (the default), this is a histogram of the number of occurences
>> of the observations at (x[i],y[i]).
>>
>> If *C* is specified, it specifies values at the coordinate
>> (x[i],y[i]). These values are accumulated for each hexagonal
>> bin and then reduced according to *reduce_C_function*, which
>> defaults to numpy's mean function (np.mean). (If *C* is
>> specified, it must also be a 1-D sequence of the same length
>> as *x* and *y*.)
> 
> What do you think? I've also implemented a simple demo making use of
> this functionality and an image of the output of the demo. For my own
> selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
> happy to hold off to get the release out the door.
> 
> -Andrew

Andrew,

That sounds like a nice addition, and one that does not interfere in any 
way with the original hexbin functionality.

Eric

Hi,

I went through all the demos in pylab_examples to make sure that
the artist.contains() method would return true when the mouse
is on the object.  I fixed a number of problems caused by the
new transforms code (collections, lines and images were not
detected).  A few issues remain, but they are not show stoppers.

Broken examples:

 barcode_demo, image_interp, etc: wx doesn't implement draw_image
 dannys_example: wx doesn't implement draw_tex
 font_table_ttf: list index out of range
 geo_demo: invalid value in projections.geo for x = ... / sinc_alpha
 multi_image: AxesImage has no attribute add_observer
 stix_fonts_demo: error
    UnicodeDecodeError: 'rawunicodeescape' codec can't decode
    bytes in position 39-0: \Uxxxxxxxx out of range
 symlog_demo: rendering causes the following error
    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
      assert len(point) == self.input_dims
 running reindent.py causes lots of changes

Hit test issues:

 barb_demo: detecting filled areas but not lines
 dashtick: not detecting dash ticks, except by tick
 date_demo2: rotated text uses bounding box rather than rotated rectangle
 newscalarformatter_demo: axis offset label not detected
 quiver_demo: 1 m/s arrow legend not detected
 scatter_star_poly: plus and star not detected

If you want to turn on hit testing for a plot, use:

    gcf().canvas.mpl_connect("motion_notify_event",
                             gcf().canvas.onHilite)


- Paul

On Sat, Jul 26, 2008 at 3:37 PM, Andrew Straw <str...@as...> wrote:
> Hi all,
>
> I've added some functionality to my copy hexbin, and I thought I'd
> bounce it off folks (esp. Michael) to see if it seems like a good idea
> to add it to MPL.

Do you mean Michiel, the hexbin author?  I m CC-ing him.


> Here's the beginning of the docstring of the new version. What I've
> added is the optional argument "C" -- inspired by scatter's "c" argument.
>
>> call signature::
>>
>>   hexbin(x, y, C = None, gridsize = 100, bins = None,
>>          xscale = 'linear', yscale = 'linear',
>>          cmap=None, norm=None, vmin=None, vmax=None,
>>          alpha=1.0, linewidths=None, edgecolors='none'
>>          reduce_C_function = np.mean,
>>          **kwargs)
>>
>> Make a hexagonal binning plot of *x* versus *y*, where *x*,
>> *y* are 1-D sequences of the same length, *N*. If *C* is None
>> (the default), this is a histogram of the number of occurences
>> of the observations at (x[i],y[i]).
>>
>> If *C* is specified, it specifies values at the coordinate
>> (x[i],y[i]). These values are accumulated for each hexagonal
>> bin and then reduced according to *reduce_C_function*, which
>> defaults to numpy's mean function (np.mean). (If *C* is
>> specified, it must also be a 1-D sequence of the same length
>> as *x* and *y*.)
>
> What do you think? I've also implemented a simple demo making use of
> this functionality and an image of the output of the demo. For my own
> selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
> happy to hold off to get the release out the door.

The functionality looks really nice.  I don't really have a problem
sneaking it in -- I'm a softie -- but  we should hear from Michiel
first. I am still waiting to hear from Sandro about his sphinx problem
before trying to release anything anyhow.

JDH

I just fixed a small bug when bins were not filled and C was specified.
Attached is the revised version.

Hi all,

I've added some functionality to my copy hexbin, and I thought I'd
bounce it off folks (esp. Michael) to see if it seems like a good idea
to add it to MPL.

Here's the beginning of the docstring of the new version. What I've
added is the optional argument "C" -- inspired by scatter's "c" argument.

> call signature::
> 
>   hexbin(x, y, C = None, gridsize = 100, bins = None,
>          xscale = 'linear', yscale = 'linear',
>          cmap=None, norm=None, vmin=None, vmax=None,
>          alpha=1.0, linewidths=None, edgecolors='none'
>          reduce_C_function = np.mean,
>          **kwargs)
> 
> Make a hexagonal binning plot of *x* versus *y*, where *x*,
> *y* are 1-D sequences of the same length, *N*. If *C* is None
> (the default), this is a histogram of the number of occurences
> of the observations at (x[i],y[i]).
> 
> If *C* is specified, it specifies values at the coordinate
> (x[i],y[i]). These values are accumulated for each hexagonal
> bin and then reduced according to *reduce_C_function*, which
> defaults to numpy's mean function (np.mean). (If *C* is
> specified, it must also be a 1-D sequence of the same length
> as *x* and *y*.)

What do you think? I've also implemented a simple demo making use of
this functionality and an image of the output of the demo. For my own
selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
happy to hold off to get the release out the door.

-Andrew

On Fri, Jul 25, 2008 at 4:12 PM, Sandro Tosi <mat...@gm...> wrote:
> On Fri, Jul 25, 2008 at 18:37, John Hunter <jd...@gm...> wrote:
>> On Fri, Jul 25, 2008 at 10:42 AM, Sandro Tosi <mat...@gm...> wrote:
>>
>>> Thanks! i've just downlaoded: is 55M tarball the real intended size?
>>> it seems a little too big... ;)
>>
>> Argg, I forgot to svn clean before I did the sdist.  Please try again.
>>
>>  http://matplotlib.sourceforge.net/tmp/matplotlib-0.98.3rc1.tar.gz
>>
>> The new file is under 6M
>
> Yeah, much better :)
>
> I've updated the package in our trunk and it's building fine.
>
> Playing with the generated doc I got an error on "matplotlib.colorbar":
>
> "
> System Message: ERROR/3
> (/home/morph/deb/build-area/matplotlib-0.98.3rc1/doc/api/colorbar_api.rst,
> line 9)
>
> Error in "automodule" directive: unknown option: "show-inheritance".

The docs require sphinx 0.4, which if I recall correctly, we got
pushed into debian on short notice precisely to support the mpl docs.
 What version of sphinx are you using?

>From our earlier thread on the subject:

Mikhail Gusarov
 to Chris, me, Sandro, Michael
	

	
Twas brillig at 00:26:04 19.06.2008 UTC+07 when
dot...@do... did gyre and gimble:

 MG> I just got a confirmation from Georg that he will release the next
 MG> version of sphinx this weekend, and I'll immediately prepare the
 MG> package.

Here we are:

Accepted:
python-sphinx_0.4-1_all.deb
 to pool/main/s/sphinx/python-sphinx_0.4-1_all.deb

On Sat, Jul 26, 2008 at 7:19 AM, David M. Kaplan <Dav...@ir...> wrote:

> I started looking at this reorganization, but it seems to me that mlab
> already has a number of functions that don't seem to have much to do
> with its initial purpose - matlab compatibility.  This was pretty
> confusing for me when I initially started using matplotlib as the mlab
> namespace was a mix of familiar and unfamiliar.

I'm not too keen on having general math in one module and matlab
compatible math in another, in part because this will be confusing to
folks not too familiar with matlab, and as time passes (I never use it
anymore) that is starting to include me.  I think we could avoid some
confusion by simply fixing the docstring in mlab.  So I'd rather put
all the math stuff in mlab, and possibly pull the geometry specific
stuff into a separate module.

> As these changes may be debatable, I haven't committed them.  Instead, I
> am attaching a patchset.  I probably won't check email this weekend, so
> I will let the powers that be decide what to do with this.

OK, thanks.  I will try nd look at this over the weekend.

> Along the way, I noticed these is some duplication in the examples
> directory between pylab_examples and mpl_examples.

mpl_examples is a sym link we use for the rest doc builds so the
examples can be included w/o the doc writer needing to know the path
structure.  That way if we want to reorganize later, we can update the
symlink rather than all the docs

jdhunter@bic128:mpl> ls -ld lib/mpl_examples
lrwxrwxrwx 1 jdhunter jdhunter 11 2008-07-25 20:37 lib/mpl_examples ->
../examples
jdhunter@bic128:mpl> ls -ld doc/mpl_examples
lrwxrwxrwx 1 jdhunter jdhunter 12 2008-06-02 07:31 doc/mpl_examples ->
../examples/

JDH

Hi,

On Fri, 2008-07-25 at 12:43 -0500, John Hunter wrote:
> Also, I would rather not put the geometry functions in cbook, eg
> distances_along_curve and path_length and friends.  Perhaps we should
> have some sort of geometry module where all these things live (there
> are some in mlab as well) but barring that I would rather have
> math/geometry stuff in mlab and general purpose helpers in cbook.
> Let's move all those before the release so we don't have to worry
> about API breakage later.
> 

I started looking at this reorganization, but it seems to me that mlab
already has a number of functions that don't seem to have much to do
with its initial purpose - matlab compatibility.  This was pretty
confusing for me when I initially started using matplotlib as the mlab
namespace was a mix of familiar and unfamiliar.

I decided instead to group several functions into a "numerical_methods"
module that includes most of my new cbook functions as well as some
linear interpolation and polygon stuff from mlab.  I moved isvector to
mlab since this really is an imitation of a matlab function of the same
name.  I have propagated these changes through to other functions in
matplotlib that use them and added remarks in CHANGELOG and API_CHANGES.

As these changes may be debatable, I haven't committed them.  Instead, I
am attaching a patchset.  I probably won't check email this weekend, so
I will let the powers that be decide what to do with this.

Along the way, I noticed these is some duplication in the examples
directory between pylab_examples and mpl_examples.

Cheers,
David

> JDH
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

John Hunter wrote:
> On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <ef...@ha...> wrote:
> 
>> This looks incomplete--shouldn't the QuiverKey initializer be using this
>> function to set the figure from Q.ax.figure, and then should be using
>> self.figure to get the transform?
>>
>> I don't want to jump in if you are in the middle of working with it, though.
>>  I don't know what your motivation for adding this function was.
> 
> All artists which contain other artists (eg QuiverKey contains a Text
> instance) should override set_figure to pass the figure on to the
> childen (we should have an ArtistContainer base class to facilitate
> stuff like this).  When we later call ax.add_artist(quiverkey), the ax
> instance will call quiverkey.set_figure so the figure will get passed
> down to the Text.  I needed to get the figure instance set on the text
> instance because the Text prop key method was using the renderer dpi
> instance in the cache key, and renderer.dpi no longer exists.  Now I
> am not nearly as familiar with QuiverKey as you are, but this was just
> a simple fix to make sure the quiverkey text instance gets its figure
> set.  If it appears to you that something is still missing, please
> clarify.

Thanks for the explanation.  The change I had in mind would not hurt, 
but it would not help, either, so we'll leave it out.

Eric

Hi,

I fixed some of the contains() methods so at least the simple
cases work.

Degenerate rectangles cause problems in axes_demo:

>>> import matplotlib.patches
>>> r = matplotlib.patches.Rectangle((0,0),1,0)   
>>> r.get_transform().inverted()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py", line 1338, in inverted
    self._inverted = Affine2D(inv(mtx))
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 332, in inv
    return wrap(solve(a, identity(a.shape[0], dtype=a.dtype)))
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy-1.1.0-py2.5-macosx-10.3-fat.egg/numpy/linalg/linalg.py", line 235, in solve
    raise LinAlgError, 'Singular matrix'
numpy.linalg.linalg.LinAlgError: Singular matrix

I've only gone through the a*.py samples, but there are a few other glitches
such as not detecting axhline/axvline, not handling rotated text properly,
and not doing very well on polar plots.  These will have to wait for another
release.

	- Paul

John Hunter wrote:
> On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:
> 
>> This is the kind of thing I would want to look at and test *very* carefully,
>> or know that someone like John or Mike has done so--which perhaps one of
>> them can do quickly.  I have looked at this dpi business with puzzlement
>> before; I don't have it all straight in my head; and I would need a chunk of
>> time to review it, which I might get in the next day or so, but can't
>> guarantee.
> 
> I just committed a fix here -- I renamed the renderer dpi instance to
> imagedpi to avoid confusion, and modified the various places in the
> artist code (collections, text) which were using renderer.dpi (they
> now use figure.dpi).   Right now the only backend that was using the
> image magnification was backend ps.

Good, thank you.

> 
>> Another aspect of the problem is that at least for use with vector backends,
>> specifying lengths in dots is unnatural; and it seems to me like something
>> to be avoided when possible even for raster backends.  I would argue that
>> pad variables should be in physical or relative units, where relative could
>> mean relative to the figure size, or to a font em, for example.  Specifying
>> lengths in dots is just asking for trouble except when the plot is not
>> intended to be scaled; when making a small png for the web, precise control
>> via lengths in dots may be helpful.
> 
> Yes, certainly points or some other physical dimension is the right
> way to specify pads.  Where in the code are dots/pixels used?

Sorry, I was misremembering; it looks like such cases were purged a long 
time ago.

Eric
> 
> JDH

John Hunter wrote:
> On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:
> 
>> This is the kind of thing I would want to look at and test *very* carefully,
>> or know that someone like John or Mike has done so--which perhaps one of
>> them can do quickly.  I have looked at this dpi business with puzzlement
>> before; I don't have it all straight in my head; and I would need a chunk of
>> time to review it, which I might get in the next day or so, but can't
>> guarantee.
> 
> I just committed a fix here -- I renamed the renderer dpi instance to
> imagedpi to avoid confusion, and modified the various places in the
> artist code (collections, text) which were using renderer.dpi (they
> now use figure.dpi).   Right now the only backend that was using the
> image magnification was backend ps.

It fixes the problems that barb_demo.py was having saving to EPS files 
here.  No noticable changes to the png files or displayed figure (as one 
would expect).

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 7:11 PM, Ryan May <rm...@gm...> wrote:

> try:
>    from hashlib import md5
> except ImportError:
>    from md5 import md5

Looks good to me -- thanks for the offer to fix this.  In general, we
only actively want to be supporting 2 python versions at a time, but
if there is an easy way to extend support to a broader range, there is
no reason not to.

JDH

On Fri, Jul 25, 2008 at 7:02 PM, Eric Firing <ef...@ha...> wrote:

> This looks incomplete--shouldn't the QuiverKey initializer be using this
> function to set the figure from Q.ax.figure, and then should be using
> self.figure to get the transform?
>
> I don't want to jump in if you are in the middle of working with it, though.
>  I don't know what your motivation for adding this function was.

All artists which contain other artists (eg QuiverKey contains a Text
instance) should override set_figure to pass the figure on to the
childen (we should have an ArtistContainer base class to facilitate
stuff like this).  When we later call ax.add_artist(quiverkey), the ax
instance will call quiverkey.set_figure so the figure will get passed
down to the Text.  I needed to get the figure instance set on the text
instance because the Text prop key method was using the renderer dpi
instance in the cache key, and renderer.dpi no longer exists.  Now I
am not nearly as familiar with QuiverKey as you are, but this was just
a simple fix to make sure the quiverkey text instance gets its figure
set.  If it appears to you that something is still missing, please
clarify.

JDH

John Hunter wrote:
> On Fri, Jul 25, 2008 at 5:47 PM, Ryan May <rm...@gm...> wrote:
> 
>> Ok, I think I found our problem, at line 859 of backend_ps.py (inside
>> _print_ps()):
>>
>>        self.figure.set_dpi(72) # Override the dpi kwarg
>>        dpi = kwargs.get("dpi", 72)
>>
>> The problem here is that while it sets the figure dpi here to 72, it's using
>> the dpi that's passed in down the chain.  Since I don't give it a dpi
>> explicity, it grabs the default dpi from my matplotlibrc, which has it set
>> to 300 dpi.  So 300 is getting passed down into the chain and I believe the
>> drawing commands are using 300 dpi.  If I change the second line above to
>> dpi = 72, I get the proper results.
> 
> Yes, we definitely need to get this fixed before any release, but we
> need to be careful here.  I had forgotten that Nicholas Young had
> submitted a patch to make the ps backend respect higher resolutions
> for embedded images
> 
>   http://www.mail-archive.com/mat...@li.../msg00353.html
> 
> so we cannot simply revert this to 72.  I also see the problem you
> pointed out in the collections module too.  While I don't have a quick
> fix at hand, at least we are starting to converge onto where the
> problems lie. Note that in the collections module the
> IdentityTransform is  bit of a red herring in the set_transforms
> method, since the collection maintains a list of transforms in
> _transforms that incorporates a dpi a draw time so I don't thing the
> standard artist transform property is used.

Yeah, I figured it was more complex thatn that.  While the 
IdentityTransform() might be a bit of a red herring, the fact remains 
that changing the dpi still changes the size of the of the marker 
relative to the canvas in a scatter plot saved with backend_ps, which 
doesn't occur with the image backends (at least I tested for png).

>> 2) backend_ps._print_figure() uses the md5 module to create a temporary
>> filename.  This module is deprecated in python 2.5 and removed (I believe)
>> in 3.0, replaced by hashlib.  Is there any opposition to changing the direct
>> use of md5.md5() to using a try...except to import md5() from it's proper
>> place?
> 
> I wasn't aware of the deprecation so I don't have any strong opinion,
> except that it wold be better if you can find a non-deprecated
> equivalent which is python 2.4 and 2.5 compatible.

Therein lies the problem, 2.5 deprecated md5 in favor of hashlib, which 
was added in 2.5.  So the options are:

1)Do nothing now.  Go back and fix the problem when we get around to
   supporting 3.x.  md5 has officially been removed from SVN for python
   3.0.
2)Move completely over to hashlib, drop support for <2.5
3)try to import md5() from hashlib, if that fails fall back to importing
   md5() from the md5 module.

Option 2 is not really an option, so never mind it.  Option 1 is the 
status quo, and it just means we need to keep it in mind as one of the 
issues that will have to be handled later when we move to 3.x.  I just 
read that in 2.6, md5 will issue a DeprecationWarning.  That probably 
kicks us to option 3.

Option 3 isn't too bad. Both the md5 objects from hashlib and from the 
md5 module support the same API. Hashlib lacks a module level function 
new() which md5 has, but this is just an alternative to using a class 
constructor, so code that uses new() (backend_svg) is easily moved over 
to code that works for both.

I'll volunteer to do the ports, which will mostly consist of:

try:
     from hashlib import md5
except ImportError:
     from md5 import md5

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Fri, Jul 25, 2008 at 6:42 PM, Eric Firing <ef...@ha...> wrote:

> This is the kind of thing I would want to look at and test *very* carefully,
> or know that someone like John or Mike has done so--which perhaps one of
> them can do quickly.  I have looked at this dpi business with puzzlement
> before; I don't have it all straight in my head; and I would need a chunk of
> time to review it, which I might get in the next day or so, but can't
> guarantee.

I just committed a fix here -- I renamed the renderer dpi instance to
imagedpi to avoid confusion, and modified the various places in the
artist code (collections, text) which were using renderer.dpi (they
now use figure.dpi).   Right now the only backend that was using the
image magnification was backend ps.

> Another aspect of the problem is that at least for use with vector backends,
> specifying lengths in dots is unnatural; and it seems to me like something
> to be avoided when possible even for raster backends.  I would argue that
> pad variables should be in physical or relative units, where relative could
> mean relative to the figure size, or to a font em, for example.  Specifying
> lengths in dots is just asking for trouble except when the plot is not
> intended to be scaled; when making a small png for the web, precise control
> via lengths in dots may be helpful.

Yes, certainly points or some other physical dimension is the right
way to specify pads.  Where in the code are dots/pixels used?

JDH

jd...@us... wrote:
> Revision: 5881
>           http://matplotlib.svn.sourceforge.net/matplotlib/?rev=5881&view=rev
> Author:   jdh2358
> Date:     2008-07-25 23:54:37 +0000 (Fri, 25 Jul 2008)
> 
> Log Message:
> -----------
> added set_figure method for quiverkey
> 
> Modified Paths:
> --------------
>     trunk/matplotlib/lib/matplotlib/quiver.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/quiver.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/quiver.py	2008-07-25 23:52:46 UTC (rev 5880)
> +++ trunk/matplotlib/lib/matplotlib/quiver.py	2008-07-25 23:54:37 UTC (rev 5881)
> @@ -296,7 +296,7 @@
>      quiverkey_doc = _quiverkey_doc
>  
>      def set_figure(self, fig):
> -        Artist.set_figure(self, fig)
> +        martist.Artist.set_figure(self, fig)
>          self.text.set_figure(fig)
>  
>  class Quiver(collections.PolyCollection):

This looks incomplete--shouldn't the QuiverKey initializer be using this 
function to set the figure from Q.ax.figure, and then should be using 
self.figure to get the transform?

I don't want to jump in if you are in the middle of working with it, 
though.  I don't know what your motivation for adding this function was.

Eric