removing the
\usepackage{times}
from sphinx.sty fixes things for you. Then we have the Computer Modern
fonts, of course...
Mike
Michael Droettboom wrote:
> John Hunter wrote:
>
>> On Thu, Jun 12, 2008 at 7:01 AM, Michael Droettboom <[EMAIL PROTECTED]>
>> wrot
John Hunter wrote:
> On Thu, Jun 12, 2008 at 7:01 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> Hmm. Isn't broken for me. I suspect we have some sort of version mismatch.
>>
>> One thing to try -- in conf.py remove the line
>>
>> \usep
ake_dvi(tex, fontsize)
> File "/usr/lib/python2.5/site-packages/matplotlib/texmanager.py",
> line 269, in make_dvi
>texfile = self.make_tex(tex, fontsize)
> File "/usr/lib/python2.5/site-packages/matplotlib/texmanager.py",
> line 248, in make_tex
>
re of
our document is parsed. Is suspect its a bug in your LaTeX distribution
that is causing package conflicts.
Cheers,
Mike
John Hunter wrote:
> On Wed, Jun 11, 2008 at 12:35 PM, John Hunter <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Jun 11, 2008 at 12:25 PM, Michael
---
>
> -
> 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
> ---
This should now be fixed in SVN.
Michael Droettboom wrote:
> Probably related to my recent PNG refactoring. (That silly error
> message is related to a different number of arguments being provided
> than expected). I'll look into it.
>
> Cheers,
> Mike
>
> Nils
o buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
>
>
> ___
> Matplotlib-devel mailing list
> Matplotl
John Hunter wrote:
> On Wed, Jun 11, 2008 at 12:25 PM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
>
>> Ok. I think I have that worked out -- would you mind testing on docutils
>> 0.4? (I don't think I broke anything that wasn't already broken...)
&g
Ok. I think I have that worked out -- would you mind testing on
docutils 0.4? (I don't think I broke anything that wasn't already
broken...)
Cheers,
Mike
Michael Droettboom wrote:
> Ah. I've got 0.5. I was hoping I wouldn't have to do that crazy
> backwar
Ah. I've got 0.5. I was hoping I wouldn't have to do that crazy
backward compatibility stuff that mathpng.py does, but it looks like
I'll have to to support 0.4. I'll look into this.
Cheers,
Mike
John Hunter wrote:
> On Wed, Jun 11, 2008 at 12:05 PM, Michael Droet
have submitted a workaround to this specific problem. Can you please
let me know if it resolves your issue?
Mike
John Hunter wrote:
> On Wed, Jun 11, 2008 at 11:24 AM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
>
>> Thanks. Done.
>>
>
> I w
You're welcome. Sorry I forgot to let you and the list know about it. ;)
Cheers,
Mike
Stan West wrote:
> Mike,
>
> I just noticed your revision 5402 to image.py. Thank you for addressing
> this.
>
> Stan
>
>
> -----Original Message-
> From: Michael
Thanks. Done.
John Hunter wrote:
> On Wed, Jun 11, 2008 at 10:52 AM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
>
>> I finished moving all of the PNG reading/writing to its own module. A
>> full rebuild is probably required after this change to ensure everyth
I finished moving all of the PNG reading/writing to its own module. A
full rebuild is probably required after this change to ensure everything
is working correctly.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science
Is anyone else working on this? I think I may have some time to this
afternoon, and I don't want to duplicate effort.
Cheers,
Mike
Michael Droettboom wrote:
> Not hard, I don't think. The following will give you a FT2Image object
> of the expression:
>
> from matp
o file a bug recommending that we revisit the
CallbackRegistry class so it doesn't get lost.
Cheers,
Mike
>
> -Original Message-
> From: Michael Droettboom [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2008 10:10
> To: Stan West
> Cc: 'John Hunter'; &
['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 o
Thanks. I have fixed 1), and added a "closed" kwarg to fill() and
Polygon.__init__() (which defaults to True to mimic behavior of 0.91 and
earlier). hist() has been updated to call fill() with closed=False.
Cheers,
Mike
Manuel Metz wrote:
> Michael Droettboom wrote:
>>
t'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
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.n
---
> 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 ma
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 argum
; 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
1:18 AM, Eric Firing <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Bryan Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
an Fodness wrote:
>
> I just upgraded to 0.98.0 and recreated a few graphs. I am
> missing parts of the edges of a fill and polygon. Any
> suggestions?
>
>
> Please post an illustrative script, as simple as possible.
>
> Eric
>
>
>
don't like this, I can remove it. It gets the ball rolling on
other CSS changes we want to make, though I suspect we want to keep them
to a minimum, as the Sphinx defaults are already pretty good.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Div
ace to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplot
ces for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
it isn't
explicit that Line2D inherits from Artist. We can, I suppose, implement
some sort of standard to always put the base classes in the docstring,
but it would be nice to automate that.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
I was able to fix this without too much trouble, so I have committed it
on the trunk.
Cheers,
Mike
Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> I see that this isn't a LaTeX error, but I think Tony's comment is
>> still somewhat valid. Since mathtext'
--
> 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
> ___________
>
ituation?
>
None of those _backend_agg.cpp changes apply to the trunk. Just replace
_backend_agg.cpp with _backend_agg.cpp.working and commit. (Or I can do
that...)
Cheers,
Mike
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Teles
Ok. This should now be fixed in r5358.
Cheers,
Mike
John Hunter wrote:
> On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> We probably want to trap for this case in the C code so it at least
>> doesn't crash, but am I right
ully the maintenance branch will be much less frequently modified
anyway. Theoretically, we should only run into merge conflicts related
to docstrings if the docstrings on the maintenance branch are themselves
edited. If we're just going to be doing bugfixes on the branch, that
seems unlikely
gt;
> In [6]:show()
> Floating point exception
>
> On the svn trunk it works.
>
> Eric
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
k the best course
of action is to just include pre-generated images in the documentation
source for this. I'll go ahead and do that.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
Darren Dale wrote:
> On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
>
>> Darren Dale wrote:
>>
>>> I'm sorry, I just don't understand how to use this.
>>>
>
> And I'm also sorry for my mild panic attack yesterd
---
> 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
> Matp
Michael Droettboom wrote:
> John Hunter wrote:
>
>> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>>> Minor point: On my machine at least, I don't have to manually clean up the
>>
John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> Minor point: On my machine at least, I don't have to manually clean up the
>> conflict files -- they are removed for me on the next commit. Those files
Disregard this -- I think John's solution looks good.
Cheers,
Mike
Michael Droettboom wrote:
> I'm happy to deal with this, but I wonder about the best path.
>
> Is it reasonable to assume that we have unicode support available in
> LaTeX and can just turn it on always,
> dvifile = self.make_dvi(tex, fontsize)
> File "/usr/lib64/python2.5/site-packages/matplotlib/texmanager.py", line
> 269, in make_dvi
> texfile = self.make_tex(tex, fontsize)
> File "/usr/lib64/python2.5/site-p
John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> So, this is more the fault of operating procedure (choosing not to do the
>> numpy renaming on the branch, for instance, which in itself was not a bad
>>
Darren Dale wrote:
> On Thursday 29 May 2008 10:15:07 am John Hunter wrote:
>
>> On Thu, May 29, 2008 at 9:11 AM, Darren Dale <[EMAIL PROTECTED]>
>>
> wrote:
>
>>> I dont understand. I thought the point of svnmerge.py was to sync the
>>> change, not to introduce conflicts. Is the proced
Darren Dale wrote:
> On Thursday 29 May 2008 10:04:34 am you wrote:
>
>> On Thu, May 29, 2008 at 9:01 AM, Darren Dale <[EMAIL PROTECTED]>
>>
> wrote:
>
>>> I am trying to merge a change to texmanager from the branch to the trunk,
>>> but something doesnt look right after I ran svnmerge.
retty confident that's the
correct fix. This has been fixed in SVN. Please try with more Korean
characters and let me know if you still see anything strange.
Cheers,
Mike
Michael Droettboom wrote:
> Correction -- no need to send the image. You said png output was
> correct, so I&#x
Correction -- no need to send the image. You said png output was
correct, so I'll just compare against that.
Michael Droettboom wrote:
> The code that generates the Type 3 fonts for us is fairly old (1995),
> and certainly predates the widespread adoption of Unicode, so I'm
y: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
>
>
> ___
> Matplotlib-devel mailing list
> M
It's a wonder that anything ever gets built against Tcl/Tk at
all... ;)
A note about my changes -- if using the tclConfig.sh fails to find a
"tk.h" file, it falls back on the old way of working, which by all
reports works for most people except on Ubuntu 8.04, so hopefully we'
nuel is the developer behind these nice new changes to hist --
> hopefully he can help you here.
>
>
> JDH
>
> -----
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com
at to merge to a
single lookup method if possible.
I'm keeping this on the trunk for now, but if we're confident in the
change, this is a good candidate to be merged to the maintenance branch.
Cheers,
Mike
Michael Droettboom wrote:
> Alas, PIL SVN head fails to build on Ubuntu 8.04
Alas, PIL SVN head fails to build on Ubuntu 8.04 (without
Ubuntu-specific patches) as well...
Cheers,
Mike
John Hunter wrote:
> On Tue, May 27, 2008 at 9:27 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> Thanks, Jonathan. The tclConfig.sh stuff was news to me (I d
==
> ...
> OPTIONAL BACKEND DEPENDENCIES
> ...
>Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
> =========
>
>
>
> I thought you are expected to pick up the correct include directori
>
> f
>
> -
> 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/
> ___
in setupext.py to say that the tk include files
> are in:
>
> /usr/include/tcl8.4
>
> ... while the tcl install home is /usr/share/tcltk. The command
> "locate tk.h" was particularly useful.
>
> Many thanks again,
>
> Jon
>
> Michael Droettboom wrot
John Hunter wrote:
> On Fri, May 23, 2008 at 11:59 AM, Michael Droettboom <[EMAIL PROTECTED]>
> wrote:
>
>> For my fellow emacs users:
>>
>> If you aren't aware of it, there is a reST mode for emacs:
>>
>> http://docutils.sourceforge.net
on
C-c a : attribute
C-c o : module
Cheers,
Mike
John Hunter wrote:
On Fri, May 23, 2008 at 8:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
Personally, I would prefer to see all the names in monospaced type (I find
it much more readable), but the additional markup may be somewh
John Hunter wrote:
> On Fri, May 23, 2008 at 8:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> Personally, I would prefer to see all the names in monospaced type (I find
>> it much more readable), but the additional markup may be somewhat at odds
>&g
Michael Droettboom wrote:
> Secondly, the ipython console sessions aren't getting syntax highlighted
> -- it would be nice if they did, particularly to indicate input vs.
> output. I'll volunteer to look into this -- I've done some pygments
> customization work in
e nice if they did, particularly to indicate input vs.
output. I'll volunteer to look into this -- I've done some pygments
customization work in the past and maybe it won't be too difficult.
Cheers,
Mike
Michael Droettboom wrote:
> These examples look great, Darren.
>
> One
hat uses png's rather
> than mathml. I'll try it when I get to work this morning, it should work in
> all browsers and we can use regular html files.
>
> Darren
>
> -
> This SF.net email is sponsore
I haven't initialized it for that direction. In a lot of ways, svnmerge
is far less useful in that case because there are many more things going
on the trunk that you don't want in the branch than vice versa.
I think in this case, a vanilla 'svn merge' (i.e. not using svnmerge.py)
is probably
Just something to keep in mind: many of the docstrings are pieced
together at import time (to avoid rewriting descriptions of common
parameters). Any tool that extracts docstrings by parsing Python rather
than importing Python may choke on that approach.
Cheers,
Mike
-
Yeah. Those all use the SWIG wrapper to Agg that we ultimately decided not to
use. I think clearing out the examples is probably a good idea -- though
moving them to some part of SVN (outside of the main trunk) might be a good
idea so we don't "lose" them. The SWIG wrapper represents a lot of
John Hunter wrote:
> On Thu, May 15, 2008 at 2:09 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> Oh joy! Maybe we should try (as Eric suggested) sscanf instead.
>>
>
> OK, I just committed a change using scanf with type %lu. tkagg svn
> trunk
Oh joy! Maybe we should try (as Eric suggested) sscanf instead.
Cheers,
Mike
John Hunter wrote:
> On Thu, May 15, 2008 at 8:08 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> I recently committed a fix (courtesy of Malte Marquarding) for segfaults
>> in the
Windows folks be willing
to compile SVN trunk and open a plot with the TkAgg backend to verify this?
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
---
a mplutil.py file).
> Thanks,
> Mark
>
> On Tue, May 13, 2008 at 7:21 PM, Michael Droettboom <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I suspect on Windows it is safe enough (in most cases) to use the
> realpath as the key, in lieu of any
gt;
> On Tue, Mar 25, 2008 at 7:50 PM, John Hunter <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>
> > The *intentio
Eric Firing wrote:
> Michael Droettboom wrote:
>
>>> I am still having a strange problem: ESP Ghostscript 815.04 (ubuntu
>>> feisty) chokes on the apostrophe in text, such as in table_demo and
>>> one or two others. I think this is just a crazy bug in this vers
Eric Firing wrote:
> John Hunter wrote:
>> On Thu, May 8, 2008 at 12:36 PM, Michael Droettboom <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Sorry, I mistyped -- it's r5082/r5083. I think those revisions were
>>> trying
>>> to deal with somethin
x has this same problem), but it's something to be aware of.
Cheers,
Mike
Michael Droettboom wrote:
> The SVG examples all look good now, as does PDF and Agg (unless I'm
> missing some small details in my quick scanning of the images).
>
> The problem with quadmesh_demo
John Hunter wrote:
> On Thu, May 8, 2008 at 12:18 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> The SVG examples all look good now, as does PDF and Agg (unless I'm missing
>> some small details in my quick scanning of the images).
>>
>> The pro
recall the issues that r5802/r5803 were trying to solve,
I'm hoping that one of you could have a look at this and have a better
idea where it's going wrong...
Cheers,
Mike
Michael Droettboom wrote:
> I'm making some progress on SVG -- all issues I've seen so far seem to
&
some warnings related to the new hist changes.
>>
>> JDH
>
> They run, but the trunk does not make valid plots in all cases. Many
> things are fouled up in SVG. The quadmesh_demo.ps is broken. I have
> not checked pdf.
>
> Eric
--
Mich
p://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotli
ed this
> weekend?
>
> The main reason I'd like to do this (instead of releasing another
> 0.91.x) is that the toolkits are broken in 0.91 - if matplotlib is
> installed as an egg basemap (or any other toolkit) cannot be installed.
>
> -Jeff
>
>
--
Michael Droettboom
;s still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourcef
---------
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael
n API, but
letting the user decide whether to combine adjacent rasterizations gets
tricky and I think is asking too much of someone who doesn't know the
mpl internals. Perhaps that is an argument against trying to implicitly
combine adjace
Eric Firing wrote:
> Michael Droettboom wrote:
>> I'm working through some recent mpl bugs in the tracker. Here's one
>> that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in
>> _subprocess.c. This file is a copy of a file included with Python
d this to SVN (branch and trunk),
since I'm reasonably confident in this code, but it would be great if a
regular Windows user could test this out and close the bug.
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescop
Michael Droettboom wrote:
> Paul Kienzle wrote:
>
>> On Mon, Apr 28, 2008 at 09:51:54AM -0400, Michael Droettboom wrote:
>>
>>
>>> Paul Kienzle wrote:
>>>
>>>
>>>> Thanks. It looks much b
Paul Kienzle wrote:
> On Mon, Apr 28, 2008 at 09:51:54AM -0400, Michael Droettboom wrote:
>
>> Paul Kienzle wrote:
>>
>>> Thanks. It looks much better in png, but pdf has the subscript raised much
>>> higher,
>>>
>> That was a
Paul Kienzle wrote:
> On Thu, Apr 24, 2008 at 08:38:02AM -0400, Michael Droettboom wrote:
>
>> Paul Kienzle wrote:
>>
>>> Hi,
>>>
>>> The superscripts in mpl don't seem to be placed at the correct height for
>>> small fonts.
John Hunter wrote:
> On Fri, Apr 25, 2008 at 2:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> I'm stumped. It looks like the code (and even the inputs to
>> draw_text_image) are virtually identical, modulo the differences between Agg
>> 2.
t was a mistake -- enforcing 1.0 pixel lines should happen
closer to the backend level -- so I've removed the max(1.0, ...) there.
> but with this change the frac bar looks a little too wide -- which is
> why I'm wondering if there is something magic about 10. or if another
> nu
until finding one that looks right.
Cheers,
Mike
John Hunter wrote:
> On Fri, Apr 25, 2008 at 1:08 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> They don't look non-antialiased to me (in your attachment or a file I
>> generated locally). Remember, the rota
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Tele
___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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 NA
iss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@list
mailing list
> [EMAIL PROTECTED]
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
--
ny experiments,
so I'm happy to be proven wrong.
> But if it's done with lines for all the backends, this means that
> draw_point() can be removed from the two files backend_agg2.py and
> backend_emf.py !?
>
Both of those backends are deprecated anyway --
services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> Matplotlib-devel mailing list
> Matplotli
use.
It looks like Darren has addressed this part...
Cheers,
Mike
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
This SF.net e
rerBase', 'SubplotTool', 'Tk', '__builtins__',
>> '__doc__', '__file__', '__name__', 'asarray', 'backend_version',
>> 'cursord', 'cursors', 'division', 'draw_if_interacti
IA
>
> -- Andrew
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
Sorry -- I see it now. Disregard my earlier message. It is now fixed
in SVN r5004.
Manuel Metz wrote:
> Happend with your commit from version 4979 -> 4989. Who's going to fix
> that ? Whom can I directly contact ?
>
> Original Message
> Subject: [matplotlib-devel] axes.py sca
Ryan May wrote:
> Eric Firing wrote:
>
>> Ryan,
>>
>> The pcolor implementation is fundamentally unsuited to large arrays.
>> Therefore I made the pcolorfast axes method, which tries to use the
>> fastest available Agg extension code, depending on the characteristics
>> of the spatial grid.
That seems like a reasonable fix. Fixed in SVN r5003.
Cheers,
Mike
Michael Fitzgerald wrote:
> Hi all,
>
> I found a small bug in LineCollection, which gives an exception when
> setting alpha. This is manifested in e.g. hlines and vlines:
>
>> In [1]: hlines((0,),(-1,),(1,),color='b',alpha=0.1
Darren Dale wrote:
> I discovered another blitting bug in backend_qt4agg.py. Qt expects a pixmap
> stringBuffer formatted in ARGB, but mpl formats in RGBA. The qt4 backend
> usually uses the _renderer.tostring_bgra method to return a properly
> formatted buffer:
>
> if QtCore.QSysInfo.ByteOrder
901 - 1000 of 1294 matches
Mail list logo
