matplotlib-devel Mailing List for matplotlib

Michael Droettboom wrote:
>> 1) A couple icons seem to be missing. See screenshot enclosed.

It looks like Gregor solved this one.

>> 1) use:
>>
>> filename.encode('ASCII', 'replace')
>>
>> on the string before using it, so that you'll get an odd name with 
>> non-ascii charactors but at least it will work.
> That seems undesirable -- you'll end up with a filename with question 
> marks in it.

Better than than a crash, and no way to save a figure, even with a 
pure-ascii filename. You could use latin-1, or even better, something 
from a system setting, though I have no idea if that's doable. The real 
solution is to allow MPL to take unicode file names -- most modern file 
systems are using unicode now.

>> 2) Use:
>> F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x 
> maintenance branch and the trunk.  Unfortunately, 0.91.2 (the latest 
> release) still has this bug.

Darn.

> This may be reason enough to push out a 
> new maintenance release of 0.91.x,

Could be -- it's kind of a show stopper.
>> MPL, I get an invalid PNG.
> Which version of MPL produces an invalid PNG? 

0.91.2

and yes, I think it is a Window bug -- I'm pretty sure it works fine on 
OS-X.

Thanks,

-CHB


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer
<gre...@gm...> wrote:

>  I also discovered this behaviour. It seems to be a Windows only specific
> behaviour that only affects the bitmaps of the disabled (or grayed out)
> toolbar buttons. A solution I found is to use the png toolbar bitmaps
> instead of of the xpm ones. For this, replace in backend_wx.py,
> NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
> same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
> wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
> bitmaps have an alpha channel, see attached file. Furthermore, in my
> opinion, the floppy symbol is too small compared to the other icons. I also
> attached a magnified version.

Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
svn branch and trunk, but I don't have ready access to wx here, so if
you or another wx svn user gets a chance to check, that would be
great.  Else I can do it tonight from home.

JDH

Chris Barker schrieb:
> Hi all,
>
> I usually use MPL embedded in wx, so I haven't noticed these before 
> but with the pylab window:
>
> 1) A couple icons seem to be missing. See screenshot enclosed.
I also discovered this behaviour. It seems to be a Windows only specific 
behaviour that only affects the bitmaps of the disabled (or grayed out) 
toolbar buttons. A solution I found is to use the png toolbar bitmaps 
instead of of the xpm ones. For this, replace in backend_wx.py, 
NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In 
the same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by 
wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the 
png bitmaps have an alpha channel, see attached file. Furthermore, in my 
opinion, the floppy symbol is too small compared to the other icons. I 
also attached a magnified version.

Gregor

Chris Barker wrote:
> Hi all,
>
> I usually use MPL embedded in wx, so I haven't noticed these before 
> but with the pylab window:
>
> 1) A couple icons seem to be missing. See screenshot enclosed.
I believe that's the way disabled buttons are drawn on Windows (or 
perhaps we need to provide disabled versions of the bitmaps on 
Windows).  Do they appear after you have panned/zoomed the plot?
>
> 2) The save button doesn't work, as I get a "cannot return std::string 
> from a Unicode object" error. This is with a unicode build of 
> wxPython. I've had this same problem with my code. This issue is that 
> the savefig code can't handle unicode (regular old fopen, I think). 
> Here are two solutions:
>
> 1) use:
>
> filename.encode('ASCII', 'replace')
>
> on the string before using it, so that you'll get an odd name with 
> non-ascii charactors but at least it will work.
That seems undesirable -- you'll end up with a filename with question 
marks in it.
>
> 2) Use:
> F.savefig(open(path, "w"), dpi=dpi)
This is exactly what matplotlib the *Agg backends do on the 0.91.x 
maintenance branch and the trunk.  Unfortunately, 0.91.2 (the latest 
release) still has this bug.  This may be reason enough to push out a 
new maintenance release of 0.91.x, but I say that having done it before ;)
>
> Python's open allows unicode filenames, and I was told that recent 
> versions of MPL can take a file, rather than just aname, without an 
> unacceptable performance hit, though in my code, without the latest 
> MPL, I get an invalid PNG.
Which version of MPL produces an invalid PNG?  I'd like to track that 
down.  It may be Windows-specific.

Cheers,
Mike
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss 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
> Mat...@li...
> 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