John,
As you may know, you're reverting the change Michael made sometime
ago. Michael said it is not a bug, but rather intended.
http://sourceforge.net/mailarchive/message.php?msg_id=6e8d907b0809031201p4bb0701eo23b3d294797a8766%40mail.gmail.com
So, I would appreciate if you reiterate this with M
Hi Eric,
As far as I know, get_window_extent is meant to return the extent of
the object in the display coordinate. And, as you may have noticed,
often this is used to calculate the relative position of objects.
I quickly went through your patch and my guess is your implementation
of get_window_
Okay.
I may work on it sometime tomorrow or during the weekends.
Regards,
-JJ
On Thu, Oct 9, 2008 at 12:54 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> Ah, that makes more sense Jae-Joon - thanks!
>
> Jae-Joon -- could
> - the parameter numpoints should be used (it's ignored right now)
>
Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
> - Some private variables are accessed and a new RegularPolycollection is
> created (does this work eg. with a StarPolygonCollection? I haven't
> check
arker points.
I was actually about to to commit my patch. I'll try to account your
changes and post my version of patch later today.
Regards,
-JJ
On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <[EMAIL PROTECTED]> wrote:
> hmm
>
> Original Message
> J
Metz <[EMAIL PROTECTED]> wrote:
> Manuel Metz wrote:
>> Jae-Joon Lee wrote:
>>> Hi Manuel,
>>>
>>> I think it is a good to introduce the update_from method in Collections.
>>> But, I'm not sure if it is a good idea to also update sizes, pat
od.
Thanks for clarifying this, John.
Manuel,
The patch looks good to me. We may submit the patch (I hope Erik is
okay with the current patch) and it would be great if you handle the
submission.
-JJ
On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <[EMAIL PROTECTED]> wrote:
> Jae-Joon L
I think it is a good idea to add such a feature in mpl, and I guess it
would better to have some general way to provide backend specific
options.
Actually, I have been using a modified version of mpl which enables to
set the individual ID of the patches (this is only meaningful in case
of the svg
Hello,
I have been putting some initial effort on implementing a new Legend
class which has paddings in canvas unit.
A related post is
http://www.mail-archive.com/[EMAIL PROTECTED]/msg08560.html
My current implementation has a same functionality as the old one (an
example figure attached), but
John,
Thanks for the advice. I'll try to put some mre effort on the documentation.
> - is using a string for connectionstyle the best choice? Ie, instead of::
>
> connectionstyle="angle,angleA=0,angleB=90,rad=10"
>
>would we rather have something like::
>
> connectionstyle=connec
rote:
>>> The current patch looks good to me... it satisfies all the use cases I
>>> had in mind, and I can't think of much else that would be wanted.
>>> Thanks!
>>>
>>> I also very much like the idea of the "sizebar," although that's
&
mes, I guess there would be no problem
I mentioned in the previous mail.
Regards,
-JJ
On Thu, Oct 30, 2008 at 7:15 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 30, 2008 at 2:59 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>> Basic idea is to create a new version
Andrew,
I just had a quick look at your patch.
I'm a bit distracted with your changes regarding the "url" support of the image.
Do we need to change the api of the draw_image()? Can we just utilize
"im" object as we did with the "gc"? Check the patch below. This
simple method seem to work fine for
Yes, the script also works for me.
It seems that the version on the web is picking up a wrong font file.
-JJ
On Sat, Nov 8, 2008 at 6:28 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>
> John,
>
> Something really went haywire on this example:
>
> http://matplotlib.sourceforge.net/examples/pylab_ex
]> wrote:
> Patch against today's svn is attached. Sorry for the long delay...
>
> Right now, "scatterpoints" is just set to 3 in Legend.__init__, but
> presumably that should be an rcParam...
>
> On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee <[EMAIL PROTECTE
Thanks John,
I'll work on the revisions.
>
> +def set_offset(self, xy):
> +"""
> +set offset of the container.
> +
> +Accept : tuple of x,y cooridnate in display units.
>
> Is it worthwhile to allow other coordinate systems for the offsets
> (points, data) or would thi
I presume my changes currently only allow loc as a location code.
I didn't know that loc can be a tuple (axes coordinate I guess?).
But it won't be hard to fix this. I'll work on it.
-JJ
On Tue, Dec 2, 2008 at 4:04 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> I think something broke with the rec
Darren,
Can you test the attached patch and see if the legend is placed where
you expected.
Regards,
-JJ
Index: lib/matplotlib/legend.py
===
--- lib/matplotlib/legend.py (revision 6477)
+++ lib/matplotlib/legend.py (working copy)
@@
The patch is now applied to the SVN (r6479).
-JJ
On Tue, Dec 2, 2008 at 5:03 PM, Darren Dale <[EMAIL PROTECTED]> wrote:
> This looks right to me, thank you Jae-Joon.
>
>
> On Tue, Dec 2, 2008 at 4:55 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>>
>> Darren,
&
John,
I just committed changes to SVN that reflect most of your comments.
I didn't add the optional transformation support yet though.
On Tue, Dec 2, 2008 at 7:45 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <[EMAIL PROTECTED
ny Yu <[EMAIL PROTECTED]> wrote:
>
> On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
>
>> John,
>>
>> I just committed changes to SVN that reflect most of your comments.
>> I didn't add the optional transformation support yet though.
>
>
> I&
Tony,
Sorry. It turned to be a bug I introduced during the update.
It should be fixed in r6499.
Thanks,
-JJ
On Fri, Dec 5, 2008 at 3:47 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
> Tony,
>
> I'll look at this problem.
> Anyhow, it seems to me that it happens because t
John,
I can't reproduce the error on my intel macbook.
Anyhow, it seems to me a bug in the code and bugs in numpy.
(I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed
in newer numpy. )
Can you try the patch below and see if this fix your problem?
-JJ
Index: lib/matplotlib/sca
I'm currently using numpy 1.1.1 and np.histogram behave differently
depending on the "new" value.
ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
this different behavior is still there.
So, as far as we're going to support numpy 1.1 and later, we may
better not to drop the "new"
arning. Could you add this?
>
> Sent from my iPhone
>
> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <[EMAIL PROTECTED]> wrote:
>
>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>> depending on the "new" value.
>>
On Mon, Dec 8, 2008 at 10:27 AM, John Hunter <[EMAIL PROTECTED]> wrote:
>
> I'm inclined to agree with you -- this could also be an rc option, so
> those who like the rounding can get them by default. I would be happy
> to have rectangle by default, with liberal use of rounding in the
> gallery ex
On Mon, Dec 8, 2008 at 12:30 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 10:49 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote:
>
>> On the other hand, I think it would also good if we allow a dictionary
>> for the "fancybox" argumen
On Mon, Dec 8, 2008 at 4:29 PM, Ryan May <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It looks like some tabs have crept into the CHANGELOG file. Is anyone
> opposed to
> me changing them to the equivalent (8) spaces? It messes up my editor, which
> is
> set to display them as 4 spaces, and makes it th
Current SVN (r6540) raise an error for the following code.
import matplotlib.pyplot as plt
import matplotlib.axes as maxes
fig = plt.figure()
ax = maxes.Subplot(fig, 1, 1, 1)
fig.add_subplot(ax)
/Users/jjlee/.virtualenvs/default/lib/python2.5/site-packages/matplotlib/figure.pyc
in add_subplot
John,
I guess the number of "=" of the first column should be 10 (now 9),
because of 'CARETRIGHT'.
I submitted the change to the TRUNK.
-JJ
On Wed, Dec 10, 2008 at 9:50 PM, John Hunter wrote:
> In response to a question on matplotlib-users, I added some additional
> documentation for the lin
Hello,
I'm thinking about slightly modifying the draw() method of the Axes
class, so that user can optionally
calculate the position of the axes at drawing time. It may be
considered as a general version of the apply_aspect() method.
For example, instead of "self.apply_aspect()" call in the draw
John and others,
I just committed a small patch that add gid(group id) as a property of
the Artist.
And also some small changes here and there, so that the svg backend
use this gid as the ID of each element. To do this, I slightly changed
the calling convention of the open_group() methods in Backe
This post is related with a bug reported in
http://sourceforge.net/tracker/index.php?func=detail&aid=2430751&group_id=80706&atid=560720
John assigned this to me, and I thought it is better to discuss with others.
First of all, I actually don't know much about the svg, so others
(someone who wrot
ented).
Here is screenshots.
http://dl.getdropbox.com/u/178748/mpl_aux/axes_divider.png
http://dl.getdropbox.com/u/178748/mpl_aux/axes_grid.png
I hope others find this useful.
Regards,
-JJ
On Wed, Dec 17, 2008 at 1:06 AM, Jae-Joon Lee wrote:
> Hello,
>
> I'm thinking about sli
Hello,
I committed a patch to optionally use preview.sty with usetex=True.
This is to support a baseline alignment.
A summary of changes:
* added a get_text_width_height_descent() method in the TexManager
class, and modified the agg, ps and pdf backends to utilize this
method.
* added a new r
On Mon, Jan 5, 2009 at 9:06 AM, Michael Droettboom wrote:
> Also, it seems like the text alignment in the PS output is too low by a
> small constant factor.
I'm not quite sure why this is happening. My guess is that it has
something to with the usage of psfrag in the ps backend, e.g., the
differe
Hi all,
I added an (experimental) bbox_inches option for savefig in the trunk.
If provided, only the specified area of the figure will be saved.
bbox_inches can be "tight", and a tight bounding box is internally
estimated (but this draws the figure twice).
Take a look at "demo_tightbbox.py".
The
Michael,
It seems that the gtk backend in the current svn silently ignores ALL
exceptions raised during the drawing.
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py?r1=6696&r2=6793
Is this necessary? I don't think we want to do this
> I'm a bit surprised to see this problem, since I imagine you guys
> build frequently. But my svn is indeed up to date and that file is
> just not there. I'm not sure which way you want the fix to go, so
> I'll leave that decision to you guys.
I believe mpl-data/matplotlibrc is not version-cont
John and Sandro,
I just had a quick look at the patch. The patch is for older version
of the mpl, and I couldn't test it yet. Anyhow, it should be straight
forward to port it to the new legend class. I'll work on it.
Meanwhile, below is a little code one may use to put the legend title
w/o modify
I just committed the support of the legend title into the trunk.
See the legend_demo3.py.
Regards,
-JJ
On Fri, Feb 13, 2009 at 3:10 PM, Jae-Joon Lee wrote:
> John and Sandro,
>
> I just had a quick look at the patch. The patch is for older version
> of the mpl, and I couldn&#
The following code show how the FontProperties is currently hashed.
def __hash__(self):
l = self.__dict__.items()
l.sort()
return hash(repr(l))
The hash does not account user's rcParams setting. And due to the font
caching, findfont(FontProperties()) returns the same
Hi Eric,
Have you find a solution for your problem?
I recently encountered a similar problem.
In my case, the images (I'm rasterizing the pcolormesh) are in wrong
size if the output dpi is other than 72.
And I guess this is related with the changes Jouni made in revision 6730.
So, can you see if
Hi,
When drawing a patch, the alpha value of its edgeolor is ignored. The
following command draw a circle whose edgecolor has alpha=1, instead
of 0.1.
gca().add_patch(Circle((0.5, 0.5), 0.3,
ec=(1,0,0,0.1), fc="none"))
Attached is a little test script and its output.
It
The example (e) in my previous script have a code and a text label mismatched.
I'm attaching the corrected one.
I took a more look on how a patch is drawn.
the draw() method of a patch calls draw_path method of the renderer,
which seems to be responsible for both "fill", and "stroke". But there
is
>
> This was causing havoc in contourf; I don't see the logic of multiplying a
> previous alpha by a new one.
Consider a following example that you want to have different alpha for
edgecolor and face color (of course this does not work as of now),
Circle((1, 1), 0.5, ec=(1, 1, 1, 0.2), fc=(1, 0,
Hi list,
I packaged some of python modules that I have been using as a mpl
toolkit. They are mostly helper classes to display images more
conveniently. Note that I put some of them in the matplotlib as
examples.
http://dl.getdropbox.com/u/178748/AxesGrid/htdocs/index.html
It consists of pure p
John,
About a week ago, I introduced my own mpl toolkit
(http://dl.getdropbox.com/u/178748/AxesGrid/htdocs/index.html) in the
mpl dev-list. And I wonder if this package can be included in the main
matplotlib source.
As a matter of fact, I was a bit reluctant to do this because the
package is poor
Eric and others,
I just committed the fix for this problem to the trunk.
It should also work with the svg backend.
>
> From a design perspective, is it appropriate for the renderer to store
> a reference to a figure? Many (all?) of the renderers seem entirely
> decoupled from the figure.
>
I ack
On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning wrote:
> On a somewhat related note, how are you turning rasterization on and
> off? Are you using my per-artist patch (which last I knew wasn't in
> trunk) or some other solution?
I remember that I tried to use your patch, but all the links that I
f
ps backend, when usetex=True, uses latex with psfrag package to
generate the output (with some extra steps).
It seems that the bounding box information is not correctly recovered
during this process.
I first thought that it would be quite difficult to get this correct,
however the attached (relativ
Hi Eric,
>
> Sorry about the broken links. I've attached a diff made against trunk
> from a few days ago.
Thanks!
>
> The discussion about what to do with my patch fizzled. I created a
> decorator that made mixed-mode switching a one-line change per artist
> type. I also added get/set_rasterized
This patch is now committed to the trunk (r7068).
-JJ
On Sat, Apr 25, 2009 at 8:29 AM, Ken Schutte wrote:
> Yeah, that seems to work! thanks a lot,
> Ken
>
> On Fri, Apr 24, 2009 at 5:21 PM, Jae-Joon Lee wrote:
>> ps backend, when usetex=True, uses latex with psfrag pack
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning wrote:
> I like that this solution doesn't litter every call to draw with
> rasterize checks. But it means that the rasterization support had
> better be robust, since Artist authors might not know they're
> interacting with the rasterization code. It
pr 29, 2009 at 3:55 PM, Darren Dale wrote:
> Hi Jae-Joon,
>
> On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee wrote:
>>
>> This patch is now committed to the trunk (r7068).
>
> I think these changes have had unintended consequences. I attached a test
> file I used to inspe
paperWidth, paperHeight = self.figure.get_size_inches()
+if isLandscape:
+paperWidth, paperHeight = paperHeight, paperWidth
else:
temp_papertype = _get_papertype(width, height)
if papertype=='auto':
On Wed, Apr 29, 2009 at 5:55 PM,
On Wed, Apr 29, 2009 at 4:07 PM, Ken Schutte wrote:
> Yes, I'm sorry, I also spoke too soon. I have found problems with
> this patch - mainly things like it chopping off xlabel, titles, etc,
> for some examples.
>
I'm not sure if these are related with my patch.
Please show some example when you
I'll revert the changes if they seem to cause more harm than good.
Regards,
-JJ
> Aside from that, the results from this patch look better. Thanks,
> Darren
>
> On Wed, Apr 29, 2009 at 5:57 PM, Jae-Joon Lee wrote:
>>
>> Argg, attached a wrong patch. This one s
4:17 PM, Eric Firing wrote:
>> Jae-Joon Lee wrote:
>>>
>>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning
>>> wrote:
>>>>
>>>> I like that this solution doesn't litter every call to draw with
>>>> rasterize checks. But it means
Thanks John,
Sorry for the buggy patch. The error occurs when usetex=False and
ps.useafm=False, which was not my setup.
Here is a patch to fix it.
--- lib/matplotlib/backends/backend_ps.py.orig 2009-05-05
14:44:31.0 -0400
+++ lib/matplotlib/backends/backend_ps.py 2009-05-05
14:44:3
I'm attaching the revised patch (I may split the patch for commit).
Regards,
-JJ
On Tue, May 5, 2009 at 3:22 PM, Eric Bruning wrote:
> To avoid confusion, how about renaming draw_wrapper._rasterized to
> draw_wrapper._supports_rasterization ?
>
> This helps to distinguish from artist._rasteri
The patches are now committed to the trunk (r7089, 7090, 7091).
Regards,
-JJ
On Tue, May 5, 2009 at 5:16 PM, Eric Bruning wrote:
> Thanks for your work on this patch JJ, glad to see it ready to go!
>
--
The NEW KODAK
Here is a slightly modified version of your script which works for me.
I don't think this is the bug in mpl. Note that the ax.bbox does
change if the canvas size change. In your original script, the
copy_from_bbox is called before frame.Show() and this seems to cause a
mismatching bbox.
My modifi
On Sat, May 9, 2009 at 7:05 PM, Elan Pavlov wrote:
> As for committing it to the repository I'd be honored if Jae Joon agrees.
Sure,
-JJ
--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
produc
I just had a quick at the patch and it looks good.
I have two minor issues.
1) API change in Axes.get_xaxis_transform & get_yaxis_transform.
The default keyword argument which=None raises an exception. Maybe
you meant which="grid"?
2) Axes.frame
Is it okay to simply drop this attribute? Any
The default resolution (which is used to interpolate a path in polar
coordinate) has change to 1 at some point. And because of this, a
radial grid becomes a 0-length line. Increasing the resolution will
bring back your gridlines.
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c'
Thanks a lot Andrew. This looks great.
I'm just reporting some of issues I encountered in a hope that you can
address these (I'll also take a look if have chance).
* cla() does not reset spines (positions, color, etc). I think it is
better to be reset, since all other things are. For example, c
The axes_grid examples, broken by the recent spine patch, are now
fixed in the svn.
Also, when I commit axes_grid toolkit into the trunk, I deleted a few
example under examples/pylab_examples. For example, axes_divider.py in
the error message below has been deleted.
IOError: [Errno 2] No such fil
Andrew,
Another issue.
The zorder of the spine artists is set to 0 by default.
I notice that you're changing the zorder of its artist attribute, but
note that it has no effect as what matter is the zorder of the spine
itself.
As a related issue to what John mentioned, I think one option you can
d
On Wed, Jun 3, 2009 at 11:04 AM, Michael Droettboom wrote:
> Jae-Joon,
>
> I just saw your curvelinear grid support fall into SVN. Very
> impressive! We actually may have a use for it here at Space Telescope
> for drawing "World Coordinate System (WCS)" plots.
>
Well, the WCS support is actuall
On Wed, Jun 3, 2009 at 11:22 AM, John Hunter wrote:
> so we may want to special case the code to handle 0.0, 0.0 as inputs.
Thanks a lot for tracking this down!
It would be best if my algorithm does not produce such a case, but
evidently it does. Yes, I'll put some code to treat this special case
John,
This should now be fixed in the svn, although I haven't actually
tested it in solaris machine.
Please check if this works.
-JJ
On Wed, Jun 3, 2009 at 4:01 PM, Jae-Joon Lee wrote:
> On Wed, Jun 3, 2009 at 11:22 AM, John Hunter wrote:
>> so we may want to special case the
Hi,
I just committed a simple patch that introduces a "rotation_mode"
property for Text artist.
By default, mpl rotates the text first and then align it. The patch
let it (optionally) align then rotate (see
examples/pylab_examples/demo_text_rotation_mode.py).
I have chosen "anchor" as the mode nam
Hello,
pywcsgrid2 is my personal project to display astronomical fits images
using matplotlib.
While there are other tools, my approach is to extend the capability
of the matplolib, rather than building something new on top of the
matplotlib. It provides a custom Axes class (derived from the
matpl
I committed the original example into the svn, and I admit that I was
not careful with the code. I agree that the arguments should be float
(the doc does say that set_alpha takes float).
The example is now updated to use floats (svn r7300).
Regards,
-JJ
On Mon, Jul 27, 2009 at 9:15 AM, Michiel
Hello,
I recently committed a support for a curvelinear grid in the axes_grid
toolkit. What it does for you is to draw a ticks and grid appropriate
for a curvelinear coordinate system, as in the example below.
http://matplotlib.sourceforge.net/_images/demo_floating_axis1.png
The main motivation
a while.
I was talking about the support for rasterization "per aritst" by
decorating the draw methods of individual artists.
-JJ
>
> Regards,
>
> Jonathan
>
>
> Jae-Joon Lee a écrit :
>> I guess this is related with the decorator introduced by rasterization
>> suppo
Hi,
There are a few new features I have committed into the svn. Nothing
significant, but hopefully useful (and fun to play with). Here is a
quick summary with screenshots ( I made a separate page because it
involves number of images).
http://abitofpythonabitofastronomy.blogspot.com/2009/08/few-ne
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 exampl
On Tue, Sep 1, 2009 at 12:57 PM, Michael Thompson wrote:
> 2009/9/1 John Hunter :
>> On Tue, Sep 1, 2009 at 10:32 AM, Michael Thompson wrote:
>>> Hi,
>>> I'm trying to work on the canvas javascript backend I found here
>>> [1]. I'm trying to add text but the canvas origin is at the top left,
>>> h
On Tue, Sep 1, 2009 at 6:03 PM, Michael Thompson wrote:
> I see firefox 3.5 (html5) has a method to measure the width of the
> text, I'll look at using this in a javascript function to render the
> text.
I'm not sure if this helps. *Matplotlib* (not the browser) needs to
know the size of the text
On Fri, Sep 4, 2009 at 4:06 PM, John Hunter wrote:
> On Fri, Sep 4, 2009 at 2:54 PM, Andrew Straw wrote:
>
>> Should I remove dvipng from the buildslaves to check for this kind of
>> thing in the future, or should I keep it installed so we can test
>> functionality that uses it?
>
> I think we shou
On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Lee wrote:
> Yes, this should be my fault. I didn't expect that importing a
> texmager would raise an exception. I'll fix it soon.
>
I just committed a changeset that I think would fix this (the
textpath.py imports texmanager only wh
Hi,
The backend_base in the trunk now has the draw_text_as_path method
which draws the text using the textpath module. The draw_text and the
draw_tex method calls it by default. This will enable a primitive
support for text and tex for all the backend which implements
draw_path method. This should
Hi,
add_line method sets label to something like "_line1" if not set.
def add_line(self, line):
if not line.get_label():
line.set_label('_line%d'%len(self.lines))
add_collection sets label to "collection1" if not set.
def add_collection(self, collection, autolim=True):
Reinier and others,
I just added a PathPatch3D class in mplot3d.art3d.
It is a slight variation of Patch3D that respect the codes the bezier
curve (I believe Patch3D does not).
An example is also added as pathpatch3d_demo.py, with a screenshot below.
http://dl.getdropbox.com/u/178748/mpl/pathpat
Thank you for reporting.
I guess this was a simple oversight.
This should be fixed in the maint. branch and the trunk.
Meanwhile, you may manually set the remove method.
im = ax.imshow(...)
im._remove_method = lambda a: ax.images.remove(a)
Regards,
-JJ
On Thu, Oct 1, 2009 at 3:56 AM, Martin T
Thanks.
I can reproduce the bug and the patch looks good.
The patch is applied to the maint. branch and the svn head.
Regards,
-JJ
On Thu, Oct 15, 2009 at 4:30 PM, Stan West wrote:
> Developers:
>
> I happened upon a small bug in which changing the rotation mode of text does
> not take effect
Hi all,
Last night, I committed a patch to support what I'm calling a
patheffect. You may think of it as a customization of the
Renderer.draw_path method.
I added an example "patheffect_demo.py" and its output is attached.
Actually, this is nothing new, and mpl already can do these kind of
thing
Can you post your patch so that others can review?
Regards,
-JJ
On Wed, Oct 21, 2009 at 3:23 AM, Georg Brandl wrote:
> Hi,
>
> one thing I missed when I switched from Gnuplot to matplotlib was that I
> can't press "q" to close a window but have to use the window manager; in
> one environment I
On Mon, Oct 26, 2009 at 2:35 AM, wrote:
> Also (a different problem), I get an error message (when adding a legend,
> that no labels were defined). This is also changed behaviour since the
> upgrade. Seems like scatter has changed... but why?
This is a known bug.
http://www.nabble.com/No-le
Thanks for your suggestion and the patch.
However, I'm not very inclined to make such a change any time soon,
since that custom axes class is one of my primary motivation
(supporting the cuvelinear grid) behind the axes_grid toolkit. And
other part of axes_grid toolkit depends on this behavior.
On
Stefan,
Can you try to install matplotlib again, after removing old ones.
The mac os X had a bug that does take care of the dpi. But I guess
this bug has been fixed in the svn.
http://old.nabble.com/Re%3A-Font-size-and-savefig-p23337463.html
-JJ
2009/11/1 Stéfan van der Walt :
> Hi John
>
> 2
I now think this is not the dpi issue.
Can you check the size of your figure in mac os X backend, after the
plot is drawn?
print f.get_size_inches()
8x6 inch is the default.
With dpi setting of 300 and bigger, the figure size (in pixel) will be
likely larger than your monitor size. And it seems
Thanks for the report.
And I wonder if you can provide us some more details of your
configuration and do some more tests.
1) You're not using usetex mode, correct?
2) Does your mathtext work fine otherwise? I mean, with the ordinary
text command, not the textpath example.
Regards,
-JJ
On Mon,
On Tue, Nov 3, 2009 at 4:23 AM, tcb wrote:
> and if I convert the dvi with dvipng, it all seems in order
> (demo_text_path_tex.png). I haven't looked closely into how the textpath
> stuff works, but I thought it would read the dvi as a path, and display that
> on the screen- if that is correct the
; cmmi12
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-25
>> cmr17
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-50
>> cmmi12
>> /usr/local/texlive/2009/texmf-dist/fo
ut I suspect freetype on the mac is passing back the
> wrong glyph. So it would seem to point to a freetype problem, or a font
> problem, and specific to the mac.
>
> I did install the latest amsfonts but the bug was still there.
>
> tcb
>
> On Wed, Nov 4, 2009 at 2:32 PM, Ja
Andrew,
One of my worry is that this can results in inconsistent ouputs
between backends. Your patch only affects backends with compositing
capabilities. And backends such as ps backend will still render images
at the bottom of all other artists.
I think it is often sufficient if we draw images a
On Mon, Nov 9, 2009 at 1:01 PM, John Hunter wrote:
> Your
> patch is only applied when len(images)<=1 or
> renderer.option_image_nocomposite(), both of which will be False when
> using Agg with multiple images, no?
I believe renderer.option_image_nocomposite() is True for the agg backend.
So, it
1 - 100 of 226 matches
Mail list logo
