matplotlib-devel Mailing List for matplotlib

Just got a new Mac, and went with Python 2.6 from python.org on OS X
10.5. My experience building Matplotlib was less than smooth, and I
thought I'd pass along what eventually wound up working.
To summarize:
1. Rolling your own libpng and freetype in /usr/local appears to lead
to a lot of architecture mismatch heartache, even though the libs
compile fine out of the box
2. The official recommendation at
http://matplotlib.sourceforge.net/users/installing.html#build-osx
doesn't work because OS X doesn't ship with wget and because the
download URLs for zlib, libpng, and freetype are broken in
matplotlib/release/osx
3. I had success by following the instructions at
http://ipython.scipy.org/moin/Py4Science/InstallationOSX, but I had to
change the build command to:
env ARCHFLAGS='-arch i386' CFLAGS="-Os -arch i386" LDFLAGS="-Os -arch
i386" python setup.py build
The ARCHFLAGS suggestion was taken from
http://www.nabble.com/Building-matplotlib-on-os-x-to24942879.html,
which had a few other scary ideas that I didn't have the heart to try.
This built (I think) an intel-only i386 (32 bit) Matplotlib, which is
fine for my local use. If I can help debug a better build process, let
me know; I can probably help test for the next week on this new
machine.
-Eric

Hi all,
Has anybody been able to confirm this as a bug? The test script is
attached to the tracker item:
https://sourceforge.net/tracker/?func=detail&aid=2832896&group_id=80706&atid=560720
I did some digging to see if I could figure out how the image scale
was being mangled. I had a hunch that it was due to some interaction
between fixed-72-dpi code, rounding the number of pixels, and
subsequent rescaling. However, the image scale still seems to be off
even when the dpi setting is a multiple of 72.
Mike
On Aug 6, 2009, at 10:42 AM, Michael Fitzgerald wrote:
>
> I've added this to the sourceforge bug tracker, ID 2832896.
>
> Mike
>
>
> On Aug 5, 2009, at 3:32 PM, Michael Fitzgerald wrote:
>
>>
>> Hi all,
>>
>> I've come across an apparent bug in imshow when outputting to PDF and EPS files. (I haven't tested other vector formats.) It manifests as a small scaling error between the raster image and the axes coordinates.
>>
>> I have attached a test script to illustrate the problem. The (correct) PNG output file shows a green 'X' at the common point between four pixels near the center of the raster image. The extent is chosen such that the coordinates refer to pixel centers. The PDF and EPS output files show a misalignment between the X and the pixel boundaries -- zoom in to see it clearly. Also, the topmost row and rightmost column appear truncated.
>>
>> I am using svn r7395.
>>
>> Thanks for the attention,
>> Mike
>>
>> <test_image_offset.py>
>
>

Hi,
I just noticed that some links in the axes_grid docs are broken, but I
have no idea what is wrong.
The broken links are those associated with the "plot" directive, i.e.,
links to its source code, hires.png and pdf.
(The links in the Gallery are fine, only those in axes_grid docs).
For example, the first plot in the overview page
(http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#axesgrid)
has a link to it source file (which is incorrect) as
http://matplotlib.sourceforge.net/mpl_toolkits/plot_directive/mpl_toolkits/axes_grid/figures/simple_axesgrid.py
The correct link is
http://matplotlib.sourceforge.net/plot_directive/mpl_toolkits/axes_grid/figures/simple_axesgrid.py
Note that the wrong link has extra "mpl_toolkits" before "plot_directive".
The relevant rest source for this plot is
.. plot:: mpl_toolkits/axes_grid/figures/simple_axesgrid.py
 :include-source:
I tried to change the path to
"mpl_examples/axes_grid/simpl_axesgrid.py", but the links are still
broken.
Any idea how to fix this?
Thanks in advance,
-JJ

Hello Gael,
Okay, I've updated the two files I modified here:
http://sites.google.com/site/jacksankey/files/matplotlib.zip?attredirects=0
Sorry I can't figure out how to compile. I wish it was possible to have an
SVN containing also the windows binaries. Too bad we all can't just run
Linux.
Anyway, I tested the pants off this using an imshow() color plot this
morning, and it works well on windows XP/wxAgg. There are two things worth
mentioning:
- For some reason, the enter key does not generate an event for me. I've
added "escape" as another possible keyboard stop event generator.
- The backspace key causes the plot to undo a zoom. This confused me for an
hour. Use delete!
- I'm fairly certain the mouse numbers are different for windows. I can't
make the middle mouse button do anything.
If you don't wind up adding all these changes, in the very least for the
upcoming release, can you please add "escape" to the list of keys that will
exit the collection of data points? That would amount to changing one line
in key_event() from
elif key == 'enter'
to
elif key in ['escape', 'enter']:
The third point above is the reason I looked into this in the first place; I
couldn't stop collecting! :) Adding 'escape' would make ginput() functional
enough. (I also use key = event.key.lower() to be safe.)
Thanks!
-Jack
On Thu, Aug 13, 2009 at 1:45 PM, Gael Varoquaux <
gae...@no...> wrote:
> On Tue, Aug 11, 2009 at 07:53:29PM -0400, Jack Sankey wrote:
> > Sorry for spamming, but I have another addition to
> > BlockingMouseInput.add_click, that fixes the problem of the graphics
> > jumping around while ginputting. This makes it much easier to zoom in
> on
> > an imshow() plot and click a bunch of points, for example (it used to
> zoom
> > all the way out!):
>
> Hey Jack,
>
> If you cannot send an 'svn diff' of your changes, would you mind sending
> the modified files all together? It is hard to review changes when
> gathering them from various mails: so easy to forget a change.
>
> Cheers,
>
> Gaël
>