Darren has kick started a documentation effort in sphinx (which
resides in the doc subdir of the trunk) that is proving quite
successful. sphinx is ReST based, and is pretty easy to jump into.
As I understand it, Darren will have some time over the summer to
contribute to the effort (porting the e
Stan,
I am cc'ing the dev list for archival reasons.
I prefer the VS2003 build for several reasons. It is faster to
build. The resulting code is faster and smaller too. This is due to
Microsoft's compiler just being better than gcc. The process is not
necessarily easier either
When I plot a matrix using pcolor, the size of the boxes don't match
the input (each box is off by about 10% from the input coordinates).
I think the problem is caused by the new draw method in PolyCollection
(added in revision 5403). If I revert to the previous version of
collections.py, th
I'm getting an error with a mathtext string from the mathtext_examples:
import matplotlib.pyplot as plt
ax = plt.subplot(111)
s = r"$W^{3\beta}_{\delta_1 \rho_1 \sigma_2} = U^{3\beta}_{\delta_1
\rho_1} + \frac{1}{8 \pi 2} \int^{\alpha_2}_{\alpha_2} d
\alpha^\prime_2 \left[\frac{ U^{2\beta}_{\delta
I've gone ahead and fixed this in the Polygon patch. As you point out,
if someone wants an open polygon, they can use PathPatch, and Polygon
was never able to do that before anyway.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Thanks. That's a good argument to do the close f
Michael Droettboom wrote:
> Thanks. That's a good argument to do the close for fill(). I'll wait a
> bit to see if others chime in, but at least at that level it seems to be
> a no-brainer. Whether we want to do this in the Polygon patch is still
> an open question, perhaps.
Mike,
Let's see
Thanks. That's a good argument to do the close for fill(). I'll wait a
bit to see if others chime in, but at least at that level it seems to be
a no-brainer. Whether we want to do this in the Polygon patch is still
an open question, perhaps.
Cheers,
Mike
Eric Firing wrote:
> Eric Firing wro
Eric Firing wrote:
> Michael Droettboom wrote:
>> I'm not entirely certain this is desirable behavior -- what if the user
>> *wants* to draw an open-yet-filled polygon? How could that be done?
>> (Admittedly, it couldn't be done before). It seems more general to
>> require the user to close p
Michael Droettboom wrote:
> I'm not entirely certain this is desirable behavior -- what if the user
> *wants* to draw an open-yet-filled polygon? How could that be done?
> (Admittedly, it couldn't be done before). It seems more general to
> require the user to close polygons.
True. I don't
BTW: Here's a patch if we decide to go that way:
Index: lib/matplotlib/patches.py
===
--- lib/matplotlib/patches.py (revision 5401)
+++ lib/matplotlib/patches.py (working copy)
@@ -540,6 +540,8 @@
See Patch documentation
I'm not entirely certain this is desirable behavior -- what if the user
*wants* to draw an open-yet-filled polygon? How could that be done?
(Admittedly, it couldn't be done before). It seems more general to
require the user to close polygons.
This change occurred as part of the big push to d
I added some custom CSS to our Sphinx HTML builds to add thin grey lines
above each class, method and function definition. I was finding it very
hard to visually see where each block of documentation begins. You may
need to blitz your documentation build directory for this to work.
If others
On Thu, Jun 5, 2008 at 12:02 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Obviously hard-codes the dpi at plot-building time. This will be dynamic:
>
> trans = fig.dpi_scale_trans + transforms.Affine2D().scale(1.0/72.0)
Alternatively you can connect to the figure dpi_changed event -- the
It's still a problem. It takes the dpi at the time of plot building and
uses that to scale each of the objects. I have followed the example of
RegularPolyCollection and now do this scaling during draw.
There was another dpi-related bug that affected the example only:
trans = transforms.Aff
On Thu, Jun 5, 2008 at 11:02 AM, Tony Yu <[EMAIL PROTECTED]> wrote:
> I think the arguments for RegularPolyCollection were changed from
> 0.91.x to 0.98.0, but the example in collections_demo.py were not
> changed.
Thanks Tony,
I committed this. Michael, when looking over the collection and
scat
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 + (i
I think the arguments for RegularPolyCollection were changed from
0.91.x to 0.98.0, but the example in collections_demo.py were not
changed.
-Tony
Index: examples/api/collections_demo.py
===
--- examples/api/collections_demo.py
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,
On Thursday 05 June 2008 08:19:47 am Michael Droettboom wrote:
> I'm going through and preparing the transforms.py documentation for our
> new Sphinx setup. One of the things that's really important to document
> is the class heirarchy, but Sphinx doesn't appear to do that. I've
> looked at the S
I'm going through and preparing the transforms.py documentation for our
new Sphinx setup. One of the things that's really important to document
is the class heirarchy, but Sphinx doesn't appear to do that. I've
looked at the Sphinx documentation and nothing comes up. I thought I'd
check with
20 matches
Mail list logo
