Hi all,
I found the recent ginput function by Gael is really cool.
On the other hand, I often need to take an input from other sources
(I mean, other than matplotlib itself, e.g., raw_input).
I don't think running a blocking function, such as a raw_input,
without freezing the figure canvas
has
the commands entered in the prompt finish.
-JJ
On Mon, Mar 10, 2008 at 7:45 PM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote:
I often need to take an input from other sources
(I mean, other than matplotlib itself, e.g., raw_input).
I
try using the Cairo backend to generate
Postscript and PDF. It may do a better job. You could also try other
Korean fonts -- they may not use compound glyph composition.
Cheers,
Mike
Jae-Joon Lee wrote:
Hello,
I wanted to render some Korean text in my matplotlib figure and this
is how
Hi,
While playing a little bit with custom_projection_example.py, I
found that plot command with projection=hammer plots too many
markers.
For example,
subplot(111, projection=hammer)
grid(True)
p = plot([-1, 1, 1], [-1, -1, 1], o)
show()
plots more than 100 circles, instead of
I forgot to attach the patch.
-JJ
On Fri, Jul 25, 2008 at 2:39 AM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
Hi,
While playing a little bit with custom_projection_example.py, I
found that plot command with projection=hammer plots too many
markers.
For example,
subplot(111, projection
Hello,
I just noticed that,if I use imshow(), part of axes border is not
clearly visible (the image hides the border).
And this seems to be due to the following changes in axes.draw()
method made in r5882.
--- lib/matplotlib/axes.py (revision 5881)
+++ lib/matplotlib/axes.py (revision
at 10:45 AM, John Hunter [EMAIL PROTECTED] wrote:
On Mon, Jul 28, 2008 at 9:26 AM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
Hello,
I just noticed that,if I use imshow(), part of axes border is not
clearly visible (the image hides the border).
And this seems to be due to the following changes
Hi all,
With the current svn, It fails with the following Exception if I try
to draw markers (I'm using GtkAgg backends and I presume this only
happens with Agg backends). Can others confirm this?
745 renderer.draw_markers(
746 gc, Path.unit_circle(), transform,
Hello,
AFAIK, current backends (I only tested agg, pdf, and ps) do not
properly respect the text baseline when text is rendered using TeX.
The get_text_width_height_descent() method in Agg and PS backends
simply return 0 for the descent value. While PDF backend uses the
dviread module to figure
On Thu, Aug 28, 2008 at 4:18 PM, John Hunter [EMAIL PROTECTED] wrote:
On Thu, Aug 28, 2008 at 2:57 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
First of all, I borrowed this idea from the PyX which is in GPL.
Although there is little of copying, other than the basic idea, I'm
not 100% sure
-and-paste
whatever code is necessary.
Of course, latex-preview is required to be installed, but I think it's a
pretty common package.
See here:
http://svn.python.org/projects/doctools/trunk/sphinx/ext/pngmath.py
Cheers,
Mike
Jae-Joon Lee wrote:
On Thu, Aug 28, 2008 at 4:18 PM, John
, 2008 at 12:04 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
Thanks,
I quickly went through the code of the pngmath.py, and it seems that
the depth(descent) of the dvi file is reported by dvipng (but the
preview package must be used in the tex file for this to work
correctly). Therefore
Hello,
When I need to use unicode string in matplotlib, I often set the font
name directly as below.
import matplotlib.font_manager as fm
fp1=fm.FontProperties(fname=/users/research/lee/.fonts/malgun.ttf)
This used to work. But not anymore. And I guess this is related with a
recent change in
Hello,
It seems that the pdf and ps backends draw the quadratic bezier line
incorrectly.
Here is a little test script.
# -- begin test script --
import matplotlib.pyplot as plt
import matplotlib
from matplotlib.path import Path
from matplotlib.patches import PathPatch
plt.clf()
ax = plt.gca()
I am getting errors any time I try to plot with markers for the points
(using the GTKAgg backend). My SVN repo copy has a lot of my own
changes in it, but I don't think these errors are associated with those
changes. Can someone confirm this is a bug? Example below.
I also don't see that
.
So, could you elaborate how you want things arranged?
Regards,
-JJ
On Thu, Sep 11, 2008 at 4:07 PM, John Hunter [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2008 at 1:13 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
It would be good if these can be included in the matplotlib. At least,
can
that implementing these fancy boxes
became possible with the bezier path support in matplotlib. So my
thanks to Michael.
On Fri, Sep 12, 2008 at 11:45 AM, John Hunter [EMAIL PROTECTED] wrote:
On Thu, Sep 11, 2008 at 4:19 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
Thanks John,
I'm afraid that I'm not quite
, but if anything is not
clear, just let me know. Also see if the current interfaces are
acceptable.
I only have placed two kind of boxstyles. I'll add more eventually.
Regards,
-JJ
On Fri, Sep 12, 2008 at 5:21 PM, John Hunter [EMAIL PROTECTED] wrote:
On Fri, Sep 12, 2008 at 2:46 PM, Jae-Joon Lee
Thanks John,
I made a single diff file and uploaded it.
https://sourceforge.net/tracker/index.php?func=detailaid=2116614group_id=80706atid=560722
Regards,
-JJ
On Wed, Sep 17, 2008 at 3:01 PM, John Hunter [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 1:30 PM, Jae-Joon Lee [EMAIL
at this carefully, but this might only happen
in some specific backends (I'm using GtkCairo). Anyhow, as a
workaround, in the draw() method, _draw_bbox() is called before the gc
is created.
On Wed, Sep 17, 2008 at 3:49 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
Thanks John,
I made a single diff
Hello,
Attached is a small patch to add a simple color mix operation support.
For example, red!30!white mixes 30% of red with 70% of white. The
syntax is borrowed from latex xcolor package
(http://www.ukern.de/tex/xcolor.html).
I found it quite handy with the fancy box thing.
plt.text(0.6, 0.5,
Thanks John,
Everything seems fine.
Thanks again,
-JJ
On Wed, Sep 17, 2008 at 4:53 PM, John Hunter [EMAIL PROTECTED] wrote:
On Wed, Sep 17, 2008 at 2:49 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
I uploaded my patch.
https://sourceforge.net/tracker/index.php?func=detailaid=2116614group_id
Thanks for the positive feedback!
Okay, I'll add a proper documentation for it and upload the patch again.
-JJ
On Thu, Sep 18, 2008 at 9:47 AM, John Hunter [EMAIL PROTECTED] wrote:
On Thu, Sep 18, 2008 at 8:35 AM, Michael Droettboom [EMAIL PROTECTED] wrote:
That's a cool feature, and one I
Hi.
I don't think my last message (sent a few days ago) made it to the
mailing list. I'm reposting it again.
On Fri, Sep 19, 2008 at 4:50 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
I just uploaded a slightly modified patch with more doumentations.
http://sourceforge.net/tracker/index.php?func
Hello,
I'm working on the fancy annotation thing I mentioned the other day,
and I want to have some feedback and advice.
As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg),
the annotation will be consist of a fancy box + fancy arrow. And my
current plan is to put the fancy
Well merging is obviously better. I wrote YAArrow to support
plain-vanilla annotations. AFAIK, they are used nowhere else, so as
long as we could come up with one arrow class that works with
plain-vanilla and fancy annotations, that would be good. But it may
be easier said than done.
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
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
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 you
- 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
checked,
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
Jae-Joon Lee wrote:
- the parameter
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, paths and
rotation (in RegularPolyCoolection). My impression is that update_from
method
,
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 Lee wrote:
Thanks Manuel.
Yes, we need rotation value
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::
probably a substantially larger job to implement. I may look into it
though, time permitting...
On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote:
To help clarify the original purpose of update_from: I wrote this
method when writing the original legend implementation so the legend
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 of the Legend class with a same
interface to the current one
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 me.
:
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 PROTECTED] wrote:
Sorry Erik.
Can you make a new patch against
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 this
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,
Can you test the attached patch and see
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] wrote:
As implementing
[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'm getting a truncated line when calling:
plt.legend(numpoints=1)
In the legend
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 the handle length is too short
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:
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
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.
ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
this different behavior is still
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 example
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 argument, like bbox in text. But maybe not in
this release.
I
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
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 jdh2...@gmail.com wrote:
In response to a question on matplotlib-users, I added some additional
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
).
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 lee.j.j...@gmail.com wrote:
Hello,
I'm thinking about
On Mon, Jan 5, 2009 at 9:06 AM, Michael Droettboom md...@stsci.edu 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,
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=6696r2=6793
Is this necessary? I don't think we want to do
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
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
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
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
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
On Tue, Apr 21, 2009 at 10:42 PM, Eric Bruning eric.brun...@gmail.com 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
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
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 and
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning eric.brun...@gmail.com 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
dsdal...@gmail.com wrote:
Hi Jae-Joon,
On Tue, Apr 28, 2009 at 3:49 PM, Jae-Joon Lee lee.j.j...@gmail.com 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 inspect the results when I wrote
, 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, Jae-Joon Lee lee.j.j
,
-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 lee.j.j...@gmail.com wrote:
Argg, attached a wrong patch. This one should work
# set the paper size to the figure size if isEPSF. The
# resulting
, Eric Firing efir...@hawaii.edu wrote:
Jae-Joon Lee wrote:
On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning eric.brun...@gmail.com
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
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
The patches are now committed to the trunk (r7089, 7090, 7091).
Regards,
-JJ
On Tue, May 5, 2009 at 5:16 PM, Eric Bruning eric.brun...@gmail.com wrote:
Thanks for your work on this patch JJ, glad to see it ready to go!
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
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
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,
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
On Wed, Jun 3, 2009 at 11:04 AM, Michael Droettboom md...@stsci.edu 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
On Wed, Jun 3, 2009 at 11:22 AM, John Hunter jdh2...@gmail.com 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
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 Leelee.j.j...@gmail.com wrote:
On Wed, Jun 3, 2009 at 11:22 AM, John Hunter jdh2...@gmail.com wrote:
so we may want to
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 name
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
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
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
support.
While most of the artist seems to explicitly require the renderer
instance
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).
On Tue, Sep 1, 2009 at 12:57 PM, Michael Thompsonmichae...@gmail.com wrote:
2009/9/1 John Hunter jdh2...@gmail.com:
On Tue, Sep 1, 2009 at 10:32 AM, Michael Thompsonmichae...@gmail.com wrote:
Hi,
I'm trying to work on the canvas javascript backend I found here
[1]. I'm trying to add text but
On Tue, Sep 1, 2009 at 6:03 PM, Michael Thompsonmichae...@gmail.com 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
On Fri, Sep 4, 2009 at 4:06 PM, John Hunterjdh2...@gmail.com wrote:
On Fri, Sep 4, 2009 at 2:54 PM, Andrew Strawstraw...@astraw.com 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
On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Leelee.j.j...@gmail.com 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 when
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
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.
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 stan.w...@nrl.navy.mil wrote:
Developers:
I happened upon a small bug in which changing the rotation mode of text
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 g.bra...@gmx.net 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
On Mon, Oct 26, 2009 at 2:35 AM, boo.da...@csiro.au 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.
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
1 - 100 of 184 matches
Mail list logo
