[matplotlib-devel] findfont not matching close weights

2008-10-22 Thread Stan West 
Greetings.  It seems that a "not" operator got dropped in rev. 6143 to
font_manager.py.  I've attached a patch.

The missing "not" tripped up findfont when trying to match font weights: the
code

fm = matplotlib.font_manager.FontManager()
fm.findfont('New Century Schoolbook', fontext='afm')

was yielding '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead of
the expected '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', because
fm.afmdict['New Century Schoolbook']['normal']['normal'] had only the
weights 500 and 700, not the 400 called for by the implicit normal weight in
the findfont call.


findfont.patch
Description: Binary data
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] findfont not matching close weights

2008-10-22 Thread Stan West 
Thank you, Mike, for your reply.  My understanding of the intent of the code
is that if the weight is not found in the font dict, setWeights is called to
supplement the dict with the missing weights, and the weight is sought again
in the supplemented dict.  That would seem to effect the desired approximate
matching, albeit by precisely matching to an enlarged font dict.  However,
Rev. 6143 replaced

if not font.has_key(weight):
setWeights(font)

with

if weight in font:
setWeights(font)

dropping the "not" and thereby supplementing the dict when the sought weight
is already present.  Restoring the "not" would restore the approximate
matching, no?

Thanks also for the fontconfig suggestion; I would be happy to try it,
except that my platform is Windows.

Stan

> -Original Message-
> From: Michael Droettboom [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, October 22, 2008 10:11
> To: Stan West
> Cc: [email protected]
> Subject: Re: [matplotlib-devel] findfont not matching close weights
> 
> This is a longstanding known issue -- the font finding 
> algorithm is way too precise, and should instead do a 
> nearest-neighbor search similar to fontconfig.  It's a 
> non-trivial bit of code that no one has yet found time for.
> 
> If you're running matplotlib 0.98.x and are on a non-Windows 
> platform, you can try the experimental fontconfig support by 
> changing the "USE_FONTCONFIG" variable to "True" in 
> font_manager.py.  (You'll need to install fontconfig on OS-X 
> -- most recent Linux distributions should already have it.)
> 
> Cheers,
> Mike
> 
> Stan West wrote:
> > Greetings.  It seems that a "not" operator got dropped in 
> rev. 6143 to 
> > font_manager.py.  I've attached a patch.
> >
> > The missing "not" tripped up findfont when trying to match font 
> > weights: the code
> >
> > fm = matplotlib.font_manager.FontManager()
> > fm.findfont('New Century Schoolbook', fontext='afm')
> >
> > was yielding 
> '...\\matplotlib\\mpl-data\\fonts\\ttf\\Vera.ttf' instead 
> > of the expected 
> '...\\matplotlib\\mpl-data\\fonts\\afm\\pncr8a.afm', 
> > because fm.afmdict['New Century 
> Schoolbook']['normal']['normal'] had 
> > only the weights 500 and 700, not the 400 called for by the 
> implicit 
> > normal weight in the findfont call.
> >   
> > 
> --
> > --
> >
> > 
> --
> > --- 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >   
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA



-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch to backend_ps for aligning Unicode text

2008-10-22 Thread Stan West 
> Stan West wrote:
> > While labeling axes with both standard and Unicode strings, I noticed some
> > alignment problems in EPS output, as in the attached examples.  I traced it
> > to differences between RendererPS.draw_text and RendererPS.draw_unicode; the
> > latter was not accounting for any descenders in the glyphs.  I've attached a
> > suggested patch which I believe brings the draw_unicode behavior into line
> > with the draw_text behavior for both AFM and TrueType fonts.  The patch also
> > removes extraneous indents in multi-line PostScript strings that were
> > appearing in the EPS files.
> >   
> Thanks for the patch.  I'm sure that was just overlooked when Unicode 
> support was added to the Ps backend.
> 
> This has been committed to SVN r6295.

You're welcome.  For my edification, are there stylistic or other reasons to 
leave the spaces in the PostScript at lines 580, 636, and 704?

> > I also noticed a related issue in backend_pdf: For both standard and Unicode
> > strings, the descender correction is computed, but the text is shifted
> > vertically in the canvas coordinate system rather than in the glyph
> > coordinate system.  Therefore, y axis labels are bumped up rather than left
> > on the canvas.  I'm not able to work on a patch at this time.
> I'll have a look at this.  Thanks for pointing it out.
> 
> Cheers,
> Mike



-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Please test this patch on windows...

2008-11-04 Thread Stan West 
I attempted to improve the dependency checking in matplotlib.__init__, using 
the subprocess
module to silence some deprecation warnings encountered with py2.6. I dont have 
access to a
Windows machine, would someone please test the attached patch or __init__.py 
file to see if it
works on that platform?
 
Thanks,
Darren

 
Do you need it tested with Python 2.5 or 2.6?
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Please test this patch on windows...

2008-11-05 Thread Stan West 
From: Darren Dale [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 05, 2008 08:48


On Tuesday 04 November 2008 05:23:19 pm you wrote:

> I attempted to improve the dependency checking in matplotlib.__init__,

> using the subprocess module to silence some deprecation warnings

> encountered with py2.6. I dont have access to a Windows machine, would

> someone please test the attached patch or __init__.py file to see if it

> works on that platform?

>

> Thanks,

> Darren

>

>

> Do you need it tested with Python 2.5 or 2.6?



2.4 through 2.6.



I'm in the process of replacing my laptop, so I should be able to check it 
myself on Vista in
two weeks.

With Python 2.5 in XP, I ran a cursory check and saw no problem initializing 
and using
matplotlib with your __init__.py. As for the other Python versions, I'm afraid 
that I have
neither of them installed.
-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] transform_angles

2008-11-05 Thread Stan West 
> From: Michael Droettboom [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 05, 2008 11:59
> 
> David Kaplan wrote:
> > Hi,
> >
> > Actually your question is a good one.  One of the reasons I never
> > finished adding an option to text objects to rotate with respect to the
> > plot (is this the correct terminology?), not the screen, is that I
> > wasn't sure of the best way to implement this without making it
> > hopelessly confusing for the user.  
> >
> > One way is to add a boolean that tells the text object whether or not
> > the angle is with respect to screen coordinates.  In this case,
> > text_obj.get_rotation() would return the angle in whichever coordinate
> > system is the active one based on the boolean, unless an option to
> > get_rotation is specified that would force the angle to the screen
> > coordinate system (this option would then be used by show methods to
> > assure they get the correct angle for plotting on the screen).
> > Similarly, set_rotation would set the angle in the active system.  The
> > disadvantage of this approach is that it can be pretty confusing -
> > unless you consult the boolean, you don't know what your angle is
> > measured relative to.
> >
> > Another approach would be to add a ._rotationPlot variable, as well
> > as .get_rotationPlot and .set_rotationPlot text-object methods.  In this
> > case, using set_rotation would set the "active" angle to be the screen
> > angle, while using set_rotationPlot would set the "active" angle to be
> > the plot angle.  The non-active angle would be set to None and show
> > calls would test for whether or not ._rotation is none, in which case
> > the screen angle would be calculated from the transform.  In this case,
> > get_rotation and get_rotationPlot would return angles in the respective
> > system, regardless of which one is "active".
> >
> > What structure would people prefer?
> >   
> I think the latter choice presents less confusion, particularly after 
> hearing your arguments.  It should probably be rotation_plot, just to be 
> consistent with other getters/setters.  There should probably also be a 
> check and warning for setting rotation_plot for figure text, where it 
> doesn't make sense, and fall back to the identity transform.

Beyond the two options of the screen coordinates and the data coordinates as 
the references, I
believe it would be useful to allow other coordinate systems.  If I wanted to 
diagonally
watermark an entire figure with, say, "DRAFT" or "PRELIMINARY," it would be 
convenient to
specify a rotation of +/- 45 degrees relative to the normalized (0-1) figure 
coordinates.  The
watermark would lie along the diagonal regardless of the aspect ratio.  
Likewise, to watermark
only a subplot, one might use the normalized axes coordinates.  It seems 
especially convenient
if users could accomplish that by passing to the text object one of the 
predefined transforms --
like ax.transData, fig.transFigure, or ax.transAxes -- to specify the 
coordinate system for the
rotation.

Would it be possible to specify the reference system and rotation angle in a 
composite transform
using transform machinery such as rotate_deg or rotate_deg_around?

> > Another reason I never finished this is that I got confused by some of
> > the code - there was talk of unitful and unitless rotations and
> > coordinates.  
> Hopefully someone else has some guidance on unit-related issues.  I 
> still don't have my head around that stuff.
> > Also, I wasn't sure what to do with objects that inherit
> > the text object class - namely, text with a dash.  It didn't seem it was
> > worth adding this non-screen rotation functionality to these objects.  
> >   
> What is the argument against?  It seems like this would be 
> straightforward (at least from the outside).  But I'm probably missing 
> something.
> > If anyone can point me in the right direction on these points, I will
> > try to finish a patch for this functionality.
> >   
> Thanks.
> 
> Mike
> > Cheers,
> > David
> >
> > On Wed, 2008-11-05 at 10:28 -0500, Michael Droettboom wrote:
> >   
> >> Darn clogged e-mail queue! ;)
> >>
> >> I see you've already addressed my question...
> >>
> >> Cheers,
> >> Mike
> >>
> >> David Kaplan wrote:
> >> 
> >>> Hi,
> >>>
> >>> I just wanted to send a note saying that I committed an additional
> >>> method to the Transforms class that transforms angles.  The basic idea
> >>> is to transform an angle at a point to a new angle at the corresponding
> >>> point in the transformed coordinate system.  The included method is
> >>> generic and should work well for almost any transform provided that the
> >>> spatial scale isn't too small or too large.  Much faster algorithms that
> >>> would work regardless of spatial scale can be found for particular
> >>> transforms, particularly affine transforms, but I haven't added these
> >>> yet.
> >>>
> >>> I also added an example script that shows how to use this method to plot
> >>> text rotated

[matplotlib-devel] Custom-sized and spanning subplots

2008-11-13 Thread Stan West 
Hello, all. I'd like to add to matplotlib facilities for (a) conveniently
specifying the relative sizes of subplots, and (b) creating subplots that span
cells of the subplot grid. For example, to obtain a column of three subplots
with the last one 50% taller than the other two, the user would provide [1, 1,
1.5] as a row size parameter, and matplotlib would calculate the appropriate
axes positions. An example of spanning using the current machinery is the
mri_with_eeg

example. Are these features of interest?

The calculation code was easy to write, but I'd like input on how it can best
be implemented and accessed by users. One issue is where the relative sizes
should be stored. Presently, while figures hold information about the margins
around and between their subplots, as far as I can tell they are unaware of
any grid structure among their subplots (although they do track as keys the
arguments to add_subplot). Grid dimensions are instead stored with each axes
along with the position of the axes within the grid. (The fact that the grid
dimensions need not agree among all of the axes in a figure allows for layouts
like mri_with_eeg. However, pushing that too far can yield unattractive
results: The axes specified by "subplot(2, 2, 1); subplot(2, 4, 5); subplot(2,
4, 6)" are misaligned unless wspace = 0, a consequence of how the wspace
parameter is interpreted. A new spanning mechanism should yield aligned axes.)

A second issue is that the numbers of rows and columns are overdetermined,
being specified explicitly by the arguments to subplot and implicitly by the
lengths of the lists containing the custom sizes.

Considering those issues, I thought of a few possible approaches for
specifying custom row and column sizes:

A. Store the row and column sizes in the instance of figure.SubplotParams held
in the figure's subplotpars attribute. User code would look something like the
following, using an example kwarg row_sizes:

fig = figure(subplotpars=mpl.figure.SubplotParams(row_sizes=[1, 1, 1.5]))
fig.add_subplot(3, 1, 1)  # etc.
fig.subplots_adjust(row_sizes=[1, 1, 3])  # resize the subplots

There would be corresponding pyplot functionality. This approach allows the
user to manage the sizes at the figure level (which I consider convenient),
but only one set of sizes is accommodated. One way to handle the overspecified
grid dimensions is a conflict-resolution scheme. For example, in
axes.SubplotBase.update_params, if the number of rows (originating in the
subplot call) matches the length of the figure's row specifier, then honor the
custom row sizes, and likewise for columns. Otherwise, either (a) raise an
error, or (b) fall back to using equal rows (or columns) but send a message to
verbose.report at some debug level. If no custom sizes are specified, then
everything operates as now and no errors nor verbose.report messages will be
generated. Because the numbers of rows and columns are stored with the axes,
each axes would handle the conflict resolution independently of the other
axes. Another scheme (which I like better) would introduce alternative subplot
syntax such as add_subplot(row, col), where row and col are numbered
Python-style from 0. That form would cause the subplot to inherit the numbers
of rows and columns and the custom sizes in fig.subplotpars, whereas the
current forms would use only equally-sized subplots. The new form also
relieves the user of constructing the Matlab-style single subplot number.

B. Instead of the above, associate the size information with the axes. User
code might resemble

fig = figure()
fig.add_subplot(2, 2, 1, col_sizes=[3, 1])  # ++ ++
fig.add_subplot(2, 2, 2, col_sizes=[3, 1])  # ++ ++
fig.add_subplot(2, 2, 3, col_sizes=[1, 3])  # ++ ++
fig.add_subplot(2, 2, 4, col_sizes=[1, 3])  # ++ ++

This continues the current ability to create different grids (different
numbers of rows and columns, only now with different row and column sizes)
within the same figure, but they're managed at the axes level. Resizing in
this approach would need to be performed with each affected axes, or a
figure-level method could walk the child axes (possibly checking for matching
numbers of rows and columns). This approach still overspecifies the numbers of
rows and columns, and conflicts would need to be resolved somehow. With the
above syntax, errors could be raised by subplot if its arguments disagree. Or,
subplot could truncate or recycle the list of sizes to match the grid
dimensions.

C. Create a new layout mechanism parallel to or containing the subplot
mechanism. I can imagine such a mechanism handling nested grids or creating
colorbar axes that adjust with their parent axes within a complex layout. Such
a mechanism would be beyond what I can contribute now working alone, but I
mention it essentially to ask whether anyone sees a need to build a new system
instead of augmenting the current one.

Re: [matplotlib-devel] Custom-sized and spanning subplots

2008-11-14 Thread Stan West 
> You may want to have a look at the mplsizer MPL toolkit I 
> wrote a long time ago and have failed to properly advertise 
> or maintain.

Thanks; I'll take a look at it.




-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Custom-sized and spanning subplots

2008-11-21 Thread Stan West 
While I check out the mplsizer toolkit, I'm still interested in any feedback
on my ideas for subplot layout features.  Does anyone have any critiques,
concerns, preferences, suggestions, etc., to voice?  Thanks.

Stan



-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Custom-sized and spanning subplots

2008-11-24 Thread Stan West 
> -Original Message-
> From: John Hunter [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 21, 2008 09:23
> 
> My main comment is to not try and reuse subplot for this.
...
> You want your grids to be irregular, so make a new subclass 
> of Axes that acts the way you want.

Understood.  I appreciate the feedback.



-
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Current recommended method for Windows builds?

2009-09-03 Thread Stan West 
Greetings.  I had previously succeeded at building matplotlib in Windows XP
using Visual Studio 2003.  (Thanks to Charlie Moad for much guidance!)  I'm
now running Win7RC and want to set up builds in that OS for Python 2.5.  I
read in the messages of May 28 about the release build script at
trunk/matplotlib/release/win32 in SVN.  So, I'm wondering whether to (a) build
as I did previously, with VS2003 or mingw using trunk/matplotlib/setup.py and
dependencies in win32_static, or (b) build with mingw using
trunk/matplotlib/release/win32/Makefile and dependencies installed there.
What approach is recommended currently?

Regarding (a), I saw Charlie's message of Apr. 10 about an updated
win32_static.zip file, but requests for
http://matplotlib.sourceforge.net/win32_static.zip and win32_static_vs.zip
yield 404s, while win32_static.tar.gz and win32_static_vs.tar.gz date
internally from 2005 and 2006, respectively.  Is the newer archive available?

Regarding (b), would I still install ActiveTCL to \Tcl and the GTK dev package
to \GTK, as in approach (a)?


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Current recommended method for Windows builds?

2009-09-04 Thread Stan West 
> From: Andrew Straw [mailto:[email protected]] 
> Sent: Thursday, September 03, 2009 14:26
>
> Hmm, it seems MS disabled Windows 7 RC downloads. So I'm 
> unable to create such a virtual machine.

One alternative is the 90-day trial of Windows 7 Enterprise:

http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Current recommended method for Windows builds?

2009-09-04 Thread Stan West 
> From: Andrew Straw [mailto:[email protected]] 
> Sent: Thursday, September 03, 2009 13:50
> 
> I am interested in getting the buildbot infrastructure to 
> build automatic nightly binaries for Windows (XP was my 
> thought, but 7 would also be good). If you you'd be willing 
> to perform the work to automate build and installation from 
> the svn repo on either your own machine or a virtual machine 
> running in my linux box (presuming I could get Windows 7 
> running in VirtualBox), you could itch your own scratch as 
> well as help the MPL community.

  . . . .

> Regardless of whether you can help with the buildbot 
> automation part, if you take notes about what you did, I'm 
> sure it will help whomever comes after you in the process.
> 
> -Andrew

Hi, Andrew.  I'm happy to share what I learn along the way.  At this point,
I'm trying to get clear about the various build approaches that are in play.
The impression I'm forming is that what I called method (a) is the legacy
method, if you will, and the developers are trying to implement two automated
build systems: one for releases -- method (b) -- and one for the buildbot, and
apparently there are some distinctions between those two.  Is that right?

By the way, my XP partition is still bootable, so I'm not restricted to Win 7
and may be able to help with an XP buildbot.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] proposed change to colors.py

2009-10-02 Thread Stan West 
> From: Dr. Phillip M. Feldman [mailto:[email protected]] 
> Sent: Thursday, October 01, 2009 20:45
> 
> Unfortunately, I'm on a Windows system, and it appears that I 
> must use SVN's GUI interface, which does not provide a 
> mechanism for saving the diff to a file.

Which GUI are you using?  If TortoiseSVN, you right-click on the modified file
and select "Create patch..." from the TortoiseSVN menu.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Text.get_prop_tup omits _rotation_mode

2009-10-15 Thread Stan West 
Developers:

I happened upon a small bug in which changing the rotation mode of text does
not take effect until another property is changed:

t = plt.text(0.5, 0.5, 'Lorem ipsum', rotation=-45)
# rotation_mode defaults to None
t.set_rotation_mode('anchor')
plt.draw()  # the new rotation mode doesn't take effect
t.set_rotation(-44)
plt.draw()  # now the angle and rotation mode are updated

This seems to be corrected by adding _rotation_mode to the properties handled
by get_prop_tup; I've attached a patch for your review.



text.Text._get_prop_tup.patch
Description: Binary data
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] SVG output: possible bug

2009-10-26 Thread Stan West 
From: Craig Lang [mailto:[email protected]] 
Sent: Monday, October 26, 2009 13:04

Greetings,

I am using matplotlib to generate an SVG plot containing a mixture of
Annotations and Circles. I noticed that the annotation text does not appear at
exactly the correct location when outputting to SVG. The difference is minor,
but definitely present.

The following will reproduce the problem in the form of two files, an svg and
a png:

[...]

Further investigation reveals that this problem occurs with ps and pdf output
as well. It seems that all backend_*.py files in
/usr/share/pyshared/matplotlib/backends suffer from this problem. I have poked
around in a few files but can't see any obvious fixes. 

Has anyone encountered this problem before and found a decent workaround? 

Thanks,
Craig

(I'm cc'ing the development list.)

I believe I have some understanding of what's happening. The backends you
mentioned use routines in ft2font.cpp to align text. The algorithms for
aligning text use information returned by the function compute_string_bbox,
which bases the bounding box on the extent of the painted regions of the
glyphs. The width and height of that box are computed by get_width_height
(also in ft2font.cpp) and returned to the renderer, which hands them off to
the _get_layout method of each text object. That method leaves the anchor
point (near the lower-left corner of the text) undisturbed for left-aligned
text, but for centered or right-aligned text shifts it left by half or all,
respectively, of the bounding box width. The resulting coordinate is returned
to the text object's draw method, which eventually calls the renderer.

The difference arises in how the renderers for the different backends treat
the anchor coordinate. The bitmap Agg backend uses draw_glyphs_to_bitmap in
ft2font.cpp, and I think that that function aligns the leftmost ink of the
bitmapped text to the anchor point. Because the anchor point was adjusted, if
at all, by the width of the inked area, it's the inked area of the text that
is left-, center-, or right-aligned. In contrast, the SVG, PS, and PDF
backends make text objects at that anchor coordinate in their output. (I'm
glossing over more complex cases like that of text converted to paths).
However, the inked area of the first character may be to the right (as with
your H) or to the left (as often with lowercase j) of the anchor point. (See,
for example, http://www.tortall.net/mu/wiki/CairoTutorial#understanding-text.)
If the text is to be center- or right-aligned, the anchor point has been
adjusted only for the width of the inked area, so any offset of the ink
relative to the initial anchor is simply translated to the other alignments.
Thus, your H was too far to the right.

I showed some different manifestations of this behavior in a tracker I filed
last year, at http://sourceforge.net/tracker/?func=detail
 &atid=560721&aid=1978234&group_id=80706. The digits and decimal points
of the y-axis tick labels are out of alignment, the x-axis tick labels have
different baselines, and the numbers in the middle are not aligned in columns
(although in PDF and SVG saves of the figure, the left-aligned numbers do lie
in columns).

I'd like to see matplotlib have at least the option of aligning using the
advance widths of the characters in the horizontal direction and the font-wide
ascent and descent (rather than the ascent and descent of the particular
glyphs in each text object) in the vertical direction. Is it important to have
the option of aligning to the glyph ink, too (and to do it consistently across
backends)? As time permits, I'm willing to contribute coding effort.

Craig, I don't know of a work-around at the moment, but I'll write again if I
think of one.

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Axis children exclude offset text

2010-05-19 Thread Stan West 
Hi, developers. While trying to set the properties of all text in a figure, I
noticed that the offset text of each axis was not being returned by
get_children(), so the offset text wasn't receiving the new properties. I
opened a tracker with a demonstration and suggested trivial patch at

http://sourceforge.net/tracker/?func=detail&atid=560720&aid=3001208&group_id=8
0706.

Thank you for your continued work on matplotlib.

--

___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Apparent bug with EPS files using Liberation fonts

2010-08-30 Thread Stan West 
Greetings. The attached script saves three EPS files (also attached) of a
figure containing a text object using the Liberation Sans font. In the three
EPS files, the text object contains no spaces, a normal space, and a
non-breaking space, respectively. Ghostscript handles the first and third
files but not the second, for which it gives the message "Error: /undefined in
--get--" at the Postscript "show" instruction for the text. I noticed that the
second file embeds a character for the non-breaking space "uni00A0" but not
the normal space, so I suppose that's why the error is occurring. I tried a
few other fonts and did not see any problems. I have matplotlib v. 1.0.0,
Python 2.6.5, and Liberation fonts 1.06.0.20100721. Would someone kindly look
into whether this might be a bug with matplotlib or the Liberation fonts? Many
thanks!

import matplotlib.pyplot as plt

fig = plt.figure()

txt = fig.text(0.5, 0.5, 'sometext', ha='center', va='center', 
   family='Liberation Sans')
fig.savefig('mpl-eps-liberation-nospace.eps')

txt.set_text('some text')
fig.savefig('mpl-eps-liberation-space.eps')

txt.set_text(u'some\u00A0text')
fig.savefig('mpl-eps-liberation-nbspace.eps')


mpl-eps-liberation-nospace.eps
Description: PostScript document


mpl-eps-liberation-space.eps
Description: PostScript document


mpl-eps-liberation-nbspace.eps
Description: PostScript document


mpl-eps-liberation-space.out
Description: Binary data
--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Apparent bug with EPS files using Liberation fonts

2010-09-01 Thread Stan West 
From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin
Root
Sent: Tuesday, August 31, 2010 23:20
 
I can confirm that evince also has a problem with the second image, but not
the first or the third images.  This is using the latest matplotlib from svn.

Thank you for the confirmation, Ben.

Here's what I've found so far. I examined the Liberation sources (the SFD
files) in FontForge and as text, and I gather that some of them use a
non-standard encoding. Liberation Sans, for example, does not define a space
glyph with the name "space"; instead it defines a glyph for the non-breaking
space at code point U+00A0 with the name "uni00A0" and gives U+0020 (the plain
space) as an alternate encoding. (In the file LiberationSans-Regular.sfd,
these definitions start at line 2929.) However, matplotlib assumes that the
font uses Postscript's StandardEncoding. I suppose that when Postscript
processes "(some text) show", it looks for the space glyph under the standard
name "space" but finds nothing. Here is an excerpt of
matplotlib/ttconv/pprdrv_tt.cpp from SVN starting at line 415:

/*-
** Define the encoding array for this font.
** Since we don't really want to deal with converting all of
** the possible font encodings in the wild to a standard PS
** one, we just explicitly create one for each font.
-*/
void ttfont_encoding(TTStreamWriter& stream, struct TTFONT *font,
std::vector& glyph_ids, font_type_enum target_type)
{
stream.putline("/Encoding StandardEncoding def");
// if (target_type == PS_TYPE_3) {
// stream.printf("/Encoding [ ");
// for (std::vector::const_iterator i = glyph_ids.begin();
//  i != glyph_ids.end(); ++i) {
// const char* name = ttfont_CharStrings_getname(font, *i);
// stream.printf("/%s ", name);
// }
// stream.printf("] def\n");
// } else {
// stream.putline("/Encoding StandardEncoding def");
// }
} /* end of ttfont_encoding() */

I saw in the SVN logs that the commented code for non-standard encodings had a
brief life of about a month earlier this year before being declared more
trouble than it was worth.

Getting back to the fonts, I found that not all of the Liberation fonts use
this non-standard encoding. The Liberation Sans Narrow fonts in the current
release define "space" at U+0020 with U+00A0 as an alternate encoding, and
they work fine in matplotlib EPS files. I also checked a few of the fonts in
one older release, 1.0
 , and they also work correctly.

One work-around I found is to use Unicode strings for text containing spaces,
which in the EPS file causes spaces to be looked up under the glyph name
"uni00A0". If embedding Type 3 fonts, another work-around (which I only
spot-checked) is to effectively standardize the encoding by editing the EPS
file, changing "/uni00A0" to "/space" in the font definition and in glyphshow
operations that call for "/uni00A0".

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Apparent bug with EPS files using Liberation fonts

2010-09-09 Thread Stan West 
From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin
Root
Sent: Thursday, September 02, 2010 14:39
 
Thanks for the insightful analysis.  Could you file a bug report with some of
this information (at the very least, reference your message on the mailing
list)?

It took me a while to get back to it, but I'm happy to file a report. The
tracker ID is 3062773.

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Spine.set_position unexpectedly clears axis

2010-09-29 Thread Stan West 
I'm setting up an axes in which I configure the axis objects with my desired
tick locators and formatters and later configure the spines, setting their
bounds, visibility, and positions. I was surprised that setting the spine
position wiped my axis formatting by calling axis.cla(). Is it necessary that
the spine must clear the registered axis when its position is changed? (The
same clearing occurs in Spine.register_axis(), but in my case that occurs at
axes creation and doesn't cause me any trouble.)

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] [PATCH] Discontinuous colormaps are reversed incorrectly

2010-10-01 Thread Stan West 
Hi, developers. I stumbled upon this when I noticed that gist_stern_r isn't
the reverse of gist_stern. As the attached script shows, the discontinuity in
red is wrong, and green stays zero instead of ramping. The problem seems to be
that when cm.revcmap() reverses a linear segment map spec (such as {'red':
[(0, 0, 0), (0.5, 1, 1), (1, 1, 1)], ...}), it doesn't swap the second and
third elements of each tuple-the color values facing in each direction. That
makes no difference for continuous colormaps but distorts discontinuous maps
such as gist_stern. I believe that the attached "cm.patch" file fixes the
problem.

The other patch, "_cm.patch", is only aesthetic after the above patch is
applied. It changes an element of the gist_stern colormap spec that should
have been unused but which caused the green channel to stay at zero with the
old revcmap. With the patched revcmap, the changed element should not be used,
but the colormap spec will look like most others with the second and third
elements of the tuple being equal.

import matplotlib as mpl
import matplotlib.pyplot as plt
import matplotlib.cm as mcmap
import numpy as np

def show_cmap_rgb(cmap, axes):
x = np.linspace(0, 1, 256)
rgba = cmap(x)
lines = []
for (idx, color) in enumerate('rgb'):
lines.extend(axes.plot(x, rgba[:, idx], ':', color=color))
axes.set_xlim(0, 1)
axes.set_ylim(-0.1, 1.1)
return lines

fig = plt.figure()

axes_f = fig.add_subplot(2, 1, 1)
show_cmap_rgb(mcmap.gist_stern, axes_f)
axes_f.set_title('Forward')

axes_r = fig.add_subplot(2, 1, 2)
show_cmap_rgb(mcmap.gist_stern_r, axes_r)
axes_r.invert_xaxis()
axes_r.set_title('Reversed')


cm.patch
Description: Binary data


_cm.patch
Description: Binary data
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Axes.autoscale_view forces tight scaling with only images

2010-10-06 Thread Stan West 
Hi again, developers. I found that Axes.autoscale_view, and therefore
Axes.autoscale, won't scale loosely when all of the children are images.
Passing tight=False yields behavior just like tight=None. The attached script
demonstrates this. In contrast, the docs for autoscale indicate that
tight=False should force loose scaling. I believe the attached patch yields
the desireable and documented behavior; would you please review it? Thank you.

For those who might need to work around the issue, the following can
accomplish a loose scaling:

axes.autoscale_view()  # tight scaling to image extent
axes.set_xbound(
*axes.xaxis.get_major_locator().view_limits(
*axes.get_xbound()))
axes.set_ybound(
*axes.yaxis.get_major_locator().view_limits(
*axes.get_ybound()))


"""
Demonstrates that, as of v. 1.0.0, Axes.autoscale_view always uses tight 
scaling when all children are images, regardless of the passed *tight* 
parameter.  Effectively, tight=False acts like tight=None.
"""

import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
import matplotlib.ticker as mtick

field = np.array([[0, 1], [1, 0]])  # image data
extent = l, r, b, t = (-1.5, 1.5, -1.5, 1.5)  # Extents will lie between ticks.
tight_seq = (None, False, True)  # values of *tight* to test

# Make two rows and a column of subplots for each *tight* value.
fig, axes = plt.subplots(2, len(tight_seq))
for ax in axes.flat:  # In all subplots, 
ax.imshow(field, extent=extent)   # show the image
ax.xaxis.set_major_locator(mtick.MultipleLocator(1))  # and set locators.
ax.yaxis.set_major_locator(mtick.MultipleLocator(1))
for ax in axes[1]: # In the second row, 
ax.plot([l, r], [b, t], 'g-')  # plot a line across the image.
for ax_row in axes:
for (ax, tight) in zip(ax_row, tight_seq):  # Apply each *tight* value
ax.autoscale_view(tight=tight)  # to the subplot...
if ax.is_first_row():
ax.set_title('tight = %s' % tight)  # and title.
plt.show()


axes.Axes.autoscale_view.patch
Description: Binary data
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Axes.autoscale_view forces tight scaling with only images

2010-10-07 Thread Stan West 
> From: Eric Firing [mailto:[email protected]] 
> Sent: Wednesday, October 06, 2010 20:53
> 
> I modified it slightly and applied to the maintenance branch.  It will 
> get merged into the trunk eventually.
> 
> Your patch as submitted was not respecting the previously-set value of 
> self._tight, hence my modification.

Thank you for the review and correction, Eric.  Your modification clarified
for me another behavior of the prior and new implementations: The argument
tight=True is retained for future autoscaling calls with tight=None, but
tight=False doesn't stick; future calls use the automatic children-based
logic.  Does the Axes._tight attribute need to have three legal values
(corresponding to tight, loose, and children-based) to yield the documented
behavior?


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Spine.set_position unexpectedly clears axis

2010-10-07 Thread Stan West 
From: Andrew Straw [mailto:[email protected]] 
Sent: Thursday, September 30, 2010 11:55
 
On 09/29/2010 08:27 AM, Stan West wrote: 

I'm setting up an axes in which I configure the axis objects with my desired
tick locators and formatters and later configure the spines, setting their
bounds, visibility, and positions. I was surprised that setting the spine
position wiped my axis formatting by calling axis.cla(). Is it necessary that
the spine must clear the registered axis when its position is changed? (The
same clearing occurs in Spine.register_axis(), but in my case that occurs at
axes creation and doesn't cause me any trouble.)

Hi Stan, IIRC, it has to do with forcing the axis elements to reconnect to the
spine after it has a new transform. If you can think of a better way to do it,
please give it a try. Simply deleting that call causes problems in some cases,
such as in the demo multiple_yaxis_with_spines.py.

Thanks, Andrew. I tried using self.axis.reset_ticks() instead of
self.axis.cla() in Spine.set_position(), and it was sufficient to give the
correct results in multiple_yaxis_with_spines.py and spine_placement_demo.py.
Going further, I made the same substitution in Spine.register_axis() and
Spine.cla(), and the example plots still looked correct. (A patch is
attached.) These latter substitutions seem okay internally, eliminating
redundant executions of Axis.cla(): The only active calls to
Spine.register_axis() are in Axes._init_axis() immediately following the
instantiation of the axis objects, and the only call I found to Spine.cla() is
in Axes.cla() right after self.xaxis.cla() and self.yaxis.cla() have occurred.
Are these changes the way to go?

Along the way, I noticed that the polar and geographic axes in
projections/polar.py and geo.py have commented-out calls to
Spine.register_axis(), to avoid calling Axis.cla(). Does the patch help
improve that situation?



spines.Spine.patch
Description: Binary data
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Suggested revisions to multiple_yaxis_with_spines example

2010-10-08 Thread Stan West 
Greetings. I initially encountered some difficulty following the
multiple_yaxis_with_spines example, especially regarding what the functions
make_patch_spines_invisible and make_spine_invisible were doing to the par2
axes and why. For example, make_spine_invisible is really making one of the
spines visible. I'd like to offer the attached modifications, which mainly
simplify the manipulations and add explanatory comments. Minor changes include
removing access to a global variable in make_patch_spines_invisible and
removing a duplicated set_xlabel. The generated figure is unchanged.



multiple_yaxis_with_spines.patch
Description: Binary data
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Annotations - negative points and pixels don't wrap

2010-12-10 Thread Stan West 
Hi. The docs for Annotation [1] say that negative coordinates given for [
figure | axes ] [ points | pixels ] xycoords are to be interpreted relative to
the top-right corner, but I found that they act relative to the bottom-left
corner as for positive coordinates. This can be seen in the attached script
and in the annotation_demo.py example [2], where the string "bottom right
(points)" bleeds off the left edge of the figure.

[1]
http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.text.Annotati
on

[2]
http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo.html

import matplotlib.pyplot as plt

fig = plt.figure()
axes = fig.add_subplot(1, 1, 1)
for x in (12, -12):
for y in (12, -12):
axes.annotate('X', (x, y), xycoords='axes points', 
  color='r', ha='center', va='center')
plt.show()
<>--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev ___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Annotations - negative points and pixels don't wrap

2010-12-22 Thread Stan West 
> From: Jae-Joon Lee [mailto:[email protected]] 
> Sent: Monday, December 13, 2010 05:24
> 
> Attached is a preliminary fix. So, please test it if you can.

Thank you.  Your fix seems to do the trick.

> I personally think it is better to use "offset points" for these cases
> which makes the internal logic much simpler.

I can see that, and that's what I was using as a work-around.


--
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] FW: [Matplotlib-users] Forcing the size of a figure

2011-08-15 Thread Stan West 
From: Stan West [mailto:[email protected]] 
Sent: Monday, August 15, 2011 13:21

From: David Just [mailto:[email protected]] 
Sent: Friday, August 12, 2011 11:05
 
Now that I'm pre-building all my enlarged interpolated images to scroll
through,  I'm having trouble forcing the figure/FigureCanvas to be the size I
want.

I'm trying: 
fig.set_size_inches(768 / 72.0, 768 / 72.0),  but it ends up the same size as
the default plot.

If the issue is that the GUI window is not changing size, try adding
"forward=True" to the set_size_inches call. 

Developers:

As I was checking this with v. 1.0.1, I noticed that the Qt4Agg and TkAgg
backends are inconsistent in how they set the size of a figure. Here is the
Qt4Agg behavior:

>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6.  3.97916667]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6.  3.4375]

The initial figure size isn't quite right, and the size after set_size_inches
is worse. (Is the resize ignoring the toolbar height?) Here is the TkAgg
behavior:

>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6.125  4.125]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6.  3.6458]

Again, the initial size is off (due to the window border?), and the resized
size is incorrect (toolbar again?).

The WXAgg backend correctly sets the figure canvas to the desired size:

>>> fig = plt.figure(figsize=[6, 4])
>>> print fig.get_size_inches()
[ 6.  4.]
>>> fig.set_size_inches([6, 4], forward=True)
>>> print fig.get_size_inches()
[ 6.  4.]

I didn't check any other backends.

I didn't see any indication in the master branch that this behavior has
changed since 1.0.1. I didn't find a report for this issue on the tracker;
shall I create one?

--
uberSVN's rich system and user administration capabilities and model 
configuration take the hassle out of deploying and managing Subversion and 
the tools developers use with it. Learn more about uberSVN and get a free 
download at:  http://p.sf.net/sfu/wandisco-dev2dev
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Calling all Mac OSX users!

2011-08-19 Thread Stan West 
> From: Christoph Gohlke [mailto:[email protected]] 
> Sent: Wednesday, August 17, 2011 04:49
> 
> On 8/16/2011 11:12 PM, Eric Firing wrote:
> >
> > The releases/win32/ tree is also unmaintained since 0.99.0.rc1.  Who
> > does the Windows builds these days?  Christophe?
> >
> > It would be nice to have a maintained record of how release builds are
> > done, or better yet, up-to-date scripts that fully automate it.
> 
> IIRC Stan West has updated those build scripts to work with Visual 
> Studio 2008 Express.

I started down that path, but I ended up using a simple CMD script instead of
a Makefile.  It takes the approach you described below of preparing include
and link flags and then calling "python setup...".  I've attached it as an
example for the mailing list, but note that the paths are specific to my
directory layout and to how I prepared the dependencies.  I've also attached
my notes from building the dependencies.  The versions described there are
circa November 2010.

> I use Visual Studio and Windows SDK compilers, whatever is the 
> officially documented and supported compiler by the targeted Python 
> version. I don't use anything from the mpl/releases/win32 tree but 
> follow the instructions at 
> <http://matplotlib.sourceforge.net/users/installing.html> and 
> <http://docs.python.org/distutils/builtdist.html>: run `python setup.py 
> bdist_wininst` after customizing setup.cfg and manually 
> building/installing all required and optional dependencies, making sure 
> they can be found by setup.py (e.g. via environment variables). I don't 
> think it is reasonable or necessary to fully automate this process 
> involving 10 python versions, ~10 dependencies, 4 compilers, and several 
> helper programs (CMake, nasm, git, tar, zip, miktex, Ghostscript). The 
> only thing worth providing might be the prebuilt static link libraries 
> and header files for zlib, libpng, and freetype for the 4 different MSC 
> compilers/runtime libraries.
@echo off
setlocal

rem  Configure Python.
rem
(set PYDIR=C:\Devel\Python26)
(set PYTHON=%PYDIR%\python.exe)

rem  Configure dependencies.
rem
(set ZLIBVERSION=1.2.5)
(set PNGVERSION=1.4.4)
(set FREETYPEVERSION=2.4.3)
(set TCLTKVERSION=8.5.2)
(set WINSRCDIR=C:\Devel)
(set ZLIBDIR=%WINSRCDIR%\zlib-%ZLIBVERSION%)
(set PNGDIR=%WINSRCDIR%\libpng-%PNGVERSION%)
(set FREETYPEDIR=%WINSRCDIR%\freetype-%FREETYPEVERSION%)
(set TCLDIR=%WINSRCDIR%\tcl%TCLTKVERSION%)
(set TKDIR=%WINSRCDIR%\tk%TCLTKVERSION%)
(set GTKDIR=%WINSRCDIR%\GTK)
(set PKG_CONFIG_PATH=%GTKDIR%\lib\pkgconfig;%PYDIR%\Lib\pkgconfig)

rem  Configure setup.py options.
rem
(set 
PY_INCLUDE="%ZLIBDIR%\include;%PNGDIR%;%FREETYPEDIR%\include;%TCLDIR%\generic;%TCLDIR%\win;%TKDIR%\generic;%TKDIR%\win;%TKDIR%\xlib")
(set PY_LINKER="%ZLIBDIR%\lib;%PNGDIR%;%FREETYPEDIR%;%PYDIR%\tcl")

rem  Build.
rem
%PYTHON% setup.py build_ext --compiler=msvc -I %PY_INCLUDE% -L %PY_LINKER% 
bdist_wininst --user-access-control=auto
rem %PYTHON% setupegg.py build_ext --compiler=msvc -I %PY_INCLUDE% -L 
%PY_LINKER% develop

endlocal & exit /b %errorlevel%


FreeType

  Downloaded "http://download.savannah.gnu.org/releases/freetype/ft243.zip".
  Extracted contents to "C:\Devel\freetype-2.4.3".
  Opened a command prompt there and executed:
  
vcvarsall.bat
vcbuild builds\win32\vc2008\freetype.vcproj Release
mklink /h freetype.lib objs\win32\vc2008\freetype243.lib
zlib

  Downloaded "http://zlib.net/zlib125.zip".
  Extracted contents to "C:\Devel\zlib-1.2.5".
  Opened a command prompt there and executed:
  
del zconf.h
mkdir build-vs9
cd build-vs9
cmake -G "Visual Studio 9 2008" -DCMAKE_INSTALL_PREFIX=..\ ..\
vcbuild zlib.vcproj "Release"
vcbuild INSTALL.vcproj "Release"
cd ..\lib
mklink /h z.lib zlib.lib
libpng

  Downloaded "http://sourceforge.net/projects/libpng/files/01-libpng-master/1.4.4/lpng144.7z".
  Extracted contents to "C:\Devel\libpng-1.4.4" (ignoring the "lpng144" subdirectory in the archive).
  Opened a command prompt there and executed:
  
vcvarsall.bat
vcbuild /upgrade projects\visualc71\libpng.vcproj
vcbuild projects\visualc71\libpng.vcproj "LIB Release"
mklink /h png.lib projects\visualc71\Win32_LIB_Release\libpng.lib
  (Instead of the above, one might try to build with CMake as was done above for zlib.)
Tcl

  Downloaded "http://sourceforge.net/projects/tcl/files/Tcl/8.5.2/tcl852-src.zip".
  Extracted contents to "C:\Devel\tcl8.5.2".
Tk

  Downloaded "http://sourceforge.net/projects/tcl/files/Tcl/8.5.2/tk852-src.zip".
  Extracted contents to "C:\Devel\tk8.5.2".
GTK

  Downloaded "http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.16/gtk+-bun

[matplotlib-devel] Fix for figsize not being honored in WXAgg & WX - How to contribute?

2008-05-21 Thread Stan West 
Greetings. I've been using matplotlib for a few weeks now in ipython on
Windows XP and with the WXAgg backend. I'm impressed by the breadth of
features and the versatility of the package. Thank you for producing such a
useful and well-made tool.
 
I noticed that the figure function was not exactly honoring the figsize
argument, as can be seen with
 
f = figure(figsize=(6, 4)); f.get_size_inches()
 
which returns approximately (5.9, 3.325) when rcParams['figure.dpi'] = 80
and (5.917, 3.4375) when rcParams['figure.dpi'] = 96. It seems that the
window frame, not the figure, takes on the given size, with some height
adjustment related to the status bar or toolbar.
 
A subsequent call to f.set_size_inches will correctly set the stored size of
the figure but not its displayed size. The set_size_inches method has a
mechanism for forwarding the new size to the window, but, according to the
docstring, that mechanism works only in the GTK backend.
 
I believe I have (1) a fix that gives new figures the size specified by
figsize, and (2) an implementation of the forward mechanism for
set_size_inches. I believe these apply to both WXAgg and WX. I'd like to
contribute them to the package; how do I do so?
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Fix for figsize not being honored in WXAgg & WX - How to contribute?

2008-05-22 Thread Stan West 
Thanks, John.  Here is the patch for the v0_91_maint branch.  As far as I
can tell, analogous changes can be made to the trunk.

Also, I believe that this resolves bug 1287318 for the WX* backends.


fix_figsize_wx.patch
Description: Binary data
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] One-pixel gap sometimes appears between AxesImage and axis frame

2008-06-05 Thread Stan West 
Hi.  When I generate an AxesImage with, say, imshow(array([[0, 1], [1,
0]])), a one-pixel gap sometimes appears between the image and the bottom
and/or right edges of the axis frame.  The gap is sometimes shaded, as if by
anti-aliasing.  The presence and shading of the gap depends on the axis
size, figure size, and figure dpi.  In particular, the gap comes and goes as
I resize the figure.  I've observed this using the WXAgg and TkAgg backends
under matplotlib 0.98.0.

I checked the trackers and mailing list archives but found no previous
mention of this behavior.

I looked into image.py but didn't readily see what might be responsible.
Would someone in the know be willing to investigate?  Many thanks in
advance.



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RegularPolyCollection inputs incollections_demo.py are wrong?

2008-06-06 Thread Stan West 
Quoting John Hunter:

> Alternatively you can connect to the figure dpi_changed event -- there is 
> an example in Axes.cla

Regarding that example, each call to Axes.cla connects a new dpi_changed
callback, but, as far as I can tell, the callback is never disconnected.
Thus, each cla call augments the dict of dpi_changed figure callbacks:

fig = figure()
ax = fig.add_subplot(1, 1, 1)
print len(fig.callbacks.callbacks['dpi_changed'])  # only 1
for n in range(7): ax.cla()
print len(fig.callbacks.callbacks['dpi_changed'])  # now 8

Should cla store the connection id and, if there is a stored id from a prior
call, disconnect the previous callback before connecting the new one?

Stan



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] RegularPolyCollection inputs incollections_demo.py are wrong?

2008-06-06 Thread Stan West 
I've not studied or used the CallbackRegistry, so I've got nothing to add on
that front.  However, may I submit the attached work-around for Axes.cla?
Instead of offsetting the title using Affine2D().translate( ... figure.dpi
... ), it uses ScaledTranslation( ... figure.dpi_scale_trans ...).  This
way, it seems to require no connection to the dpi_changed event (thereby
sidestepping the callback accumulation).  Also, it constructs
titleOffsetTrans similarly to get_xaxis_text1_transform and its relatives,
and it reduces the hard-coded 5-point offset from three occurences to one,
which helps any future conversion to an rcParam.

I verified that the old and new code produce the same transformation matrix.
However, when I tried to retrieve the title's transformation, I received a
rather long traceback.  It can be reproduced with

import matplotlib.transforms as mtransforms
mtransforms.ScaledTranslation(0, 0, mtransforms.IdentityTransform())

under 0.98.0.  Now, how far have we deviated from the subject line? :-)


-Original Message-
From: Michael Droettboom [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 06, 2008 10:10
To: Stan West
Cc: 'John Hunter'; 'matplotlib-dev list'
Subject: Re: [matplotlib-devel] RegularPolyCollection inputs
incollections_demo.py are wrong?

You're absolutely right that it needs to be fixed.

However, I wonder why the CallbackRegistry doesn't just store the callbacks
in a set (or keys of a dictionary) such that multiple adds of the exact same
function or method to the same signal couldn't occur.  
Since there is no external state stored with each callback, I don't see a
need for there ever being more than one of the same thing in there... 
but maybe I'm missing something.  Additionally, it seems like a C-ism to
have to deal with callback ids when the callback objects themselves are
already hashable and could be used to remove themselves.

Cheers,
Mike

Stan West wrote:
> Quoting John Hunter:
>
>   
>> Alternatively you can connect to the figure dpi_changed event -- 
>> there is an example in Axes.cla
>> 
>
> Regarding that example, each call to Axes.cla connects a new 
> dpi_changed callback, but, as far as I can tell, the callback is never
disconnected.
> Thus, each cla call augments the dict of dpi_changed figure callbacks:
>
> fig = figure()
> ax = fig.add_subplot(1, 1, 1)
> print len(fig.callbacks.callbacks['dpi_changed'])  # only 1
> for n in range(7): ax.cla()
> print len(fig.callbacks.callbacks['dpi_changed'])  # now 8
>
> Should cla store the connection id and, if there is a stored id from a 
> prior call, disconnect the previous callback before connecting the new
one?
>
> Stan
>
>
>   

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA



axes.Axes.titleOffsetTrans.patch
Description: Binary data
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object has no attribute 'SetInitialSize'

2008-06-10 Thread Stan West 
Greetings.  According to http://www.wxpython.org/recentchanges.php,
SetInitialSize became available at version 2.7.2.0 (7 Nov 2006) of wxPython.
It renamed the prior SetBestFittingSize, for which I found no other mention
in the changes document.  (That version history lists those methods as
belonging to wx.Window, from which wx.Panel inherits.)

Stan


-Original Message-
From: John Hunter [mailto:[EMAIL PROTECTED] 
Sent: Monday, June 09, 2008 16:05
To: Nils Wagner
Cc: [email protected]; Stan West
Subject: Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object
has no attribute 'SetInitialSize'

On Sat, Jun 7, 2008 at 4:36 AM, Nils Wagner <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> I have some trouble with matplotlib's svn version.
> Any pointer would be appreciated.
> self.canvas.SetInitialSize(wx.Size(fig.bbox.width,
> fig.bbox.height))
> AttributeError: 'FigureCanvasWxAgg' object has no attribute 
> 'SetInitialSize'

This came from Stan's patch to fix figure sizing in wx.  Nils, could you
report your wx version, and Stan, could you see if there is a version
problem in the SetInitialSize call?

Thanks,
JDH



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Repair of baseline alignment in Text._get_layout

2008-06-10 Thread Stan West 
Hi.  A few days ago, I submitted a patch (1985420) to repair text baseline
alignment, but I'm wondering if it hasn't come to a developer's attention.
The following is a simple test script for the behavior:

figure()
plot([0])
grid()
text(0, 0, 'Baseline at 0?', va='baseline')

The fix is merely a sign change.

Generally, is it preferable to submit patches through the SourceForge
tracker or to the matplotlib-devel list?



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] One-pixel gap sometimes appears between AxesImage and axis frame

2008-06-11 Thread Stan West 
Mike,

I just noticed your revision 5402 to image.py.  Thank you for addressing
this.

Stan 


-Original Message-
From: Michael Droettboom [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 05, 2008 12:03
To: Stan West
Cc: [email protected]
Subject: Re: [matplotlib-devel] One-pixel gap sometimes appears between
AxesImage and axis frame

This happens because the axes rectangle is rounded to the nearest pixels by
(essentially, hand-waving over the details) doing

 (int)x0, (int)y0, (int)x1, (int)y1

where x0, y0, x1, y1 are the bounds of the box, whereas images are rounded
to the nearest pixels by:

 (int)x0, (int)y0, (int)x0 + (int)width, (int)y0 + (int)height

This should be fixable, but the implementation details make it a little
tricky.  I'm looking into this and will get back to you.

Cheers,
Mike

Stan West wrote:
> Hi.  When I generate an AxesImage with, say, imshow(array([[0, 1], [1, 
> 0]])), a one-pixel gap sometimes appears between the image and the 
> bottom and/or right edges of the axis frame.  The gap is sometimes 
> shaded, as if by anti-aliasing.  The presence and shading of the gap 
> depends on the axis size, figure size, and figure dpi.  In particular, 
> the gap comes and goes as I resize the figure.  I've observed this 
> using the WXAgg and TkAgg backends under matplotlib 0.98.0.
>
> I checked the trackers and mailing list archives but found no previous 
> mention of this behavior.
>
> I looked into image.py but didn't readily see what might be responsible.
> Would someone in the know be willing to investigate?  Many thanks in 
> advance.
>
>
>
> --
> --- Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about anything 
> Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA




-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object has no attribute 'SetInitialSize'

2008-06-11 Thread Stan West 
Hi, John.  With the change, "fig = figure(figsize=(w, h))" properly creates
a figure window with a correctly-sized canvas, but "fig.set_size_inches((w,
h), forward=True)" raises

AttributeError: 'FigureCanvasWxAgg' object has no attribute
'SetSizeFunc'

in FigureManagerWx.resize.  Previously, the SetInitialSize called by
FigureFrameWx.__init__ and FigureManagerWx.resize was an attribute of the
canvas, but the new code makes SetSizeFunc an attribute of the frame
instead.  FigureManagerWx.resize was still looking under the canvas.

Would you please look over the attached patch?  During
FigureCanvasWx.__init__, it connects FigureCanvasWx.SetInitialSize to
SetBestFittingSize or do_nothing if it isn't already inherited from
wx.Panel.  FigureFrameWx.__init__ and FigureManagerWx.resize just call
FigureCanvasWx.SetInitialSize.

Stan


-Original Message-
From: John Hunter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 10, 2008 10:31
To: Stan West
Cc: Nils Wagner; [email protected]
Subject: Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object
has no attribute 'SetInitialSize'

On Tue, Jun 10, 2008 at 9:21 AM, Stan West <[EMAIL PROTECTED]> wrote:
> Greetings.  According to http://www.wxpython.org/recentchanges.php,
> SetInitialSize became available at version 2.7.2.0 (7 Nov 2006) of
wxPython.
> It renamed the prior SetBestFittingSize, for which I found no other 
> mention in the changes document.  (That version history lists those 
> methods as belonging to wx.Window, from which wx.Panel inherits.)

OK, I committed a change to svn using:

def do_nothing(*args, **kwargs):
warnings.warn('could not find a SetSizeFunc for backend_wx;
please report your wxpython version=%s to the matplotlib developers
list'%backend_version)
pass

# try to find the set size func across wx versions
self.SetSizeFunc = getattr(self.canvas, 'SetInitialSize',
   getattr(self.canvas,
'SetBestFittingSize', do_nothing))
self.SetSizeFunc(wx.Size(fig.bbox.width, fig.bbox.height))


Could you guys test from svn on your respective wx versions and/or check
that the logic looks correct here?

Thanks,
JDH


backend_wx.patch
Description: Binary data
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Backend names in matplotlibrc

2008-06-13 Thread Stan West 
Greetings. It seems that the list of backends in the matplotlibrc.template
file is out-of-sync with the available backend names. In particular,
"Qt4Agg", "CocoaAgg", and "emf" are missing, and "GD" and "Paint" are
present but not available.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Axes properties are cleared after offsetting spines

2014-03-24 Thread Stan West 

On 2014-03-24 14:08, Stan West wrote:
May I suggest that you look at the mailing list thread from that time 
[1], try the patch in the thread, and see whether your issue is 
resolved? This solution doesn't provide a work-around in your code, 
but it may fix the problem at the root.
Paul, I just found the work-around that I used in my code. Define the 
following function:


   def set_spine_position(spine, position):
"""
Set the spine's position without resetting an associated axis.

As of matplotlib v. 1.0.0, if a spine has an associated axis, then

spine.set_position() calls axis.cla(), which resets locators, 
formatters,
etc.  We temporarily replace that call with axis.reset_ticks(), which is
sufficient for our purposes.
"""
axis = spine.axis
if axis is not None:
cla = axis.cla
axis.cla = axis.reset_ticks
spine.set_position(position)
if axis is not None:
axis.cla = cla

(The mention of v. 1.0.0 in the docstring is just the version I was 
using at the time, not necessarily the earliest version with this 
issue.) Then replace method calls like "spine.set_position(pos)" with 
the function call "set_spine_position(spine, pos)". I hope this helps.
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Axes properties are cleared after offsetting spines

2014-03-24 Thread Stan West 

On 2014-02-05 02:26, Paul Hobson wrote:
I noticed that when you offset the spines of an Axes object, the 
labels, ticks, and ticklabels/formatting get mostly cleared. Is this 
intentional and is there a way to prevent (or undo) it?

[...]

Paul, I may have encountered the same issue a few years ago. May I 
suggest that you look at the mailing list thread from that time [1], try 
the patch in the thread, and see whether your issue is resolved? This 
solution doesn't provide a work-around in your code, but it may fix the 
problem at the root. I took a brief look at the current state of 
spines.py, and I found only the same instances of "self.axis.cla()" that 
the patch changes to "self.axis.reset_ticks()".


Kind regards,

Stan

[1] 
http://matplotlib.1069221.n5.nabble.com/Spine-set-position-unexpectedly-clears-axis-td37865.html, 
29 Sep. 2010.
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel