matplotlib-users Mailing List for matplotlib

Thanks again for your help!
I can confirm that your patch works, and appreciate it. I'm almost
surprised that I'd be one of the few running codes that would find a problem
such as this, with plotting repeatedly over a large number of iterations.
On Feb 1, 2008 11:22 AM, Michael Droettboom <md...@st...> wrote:
> Thanks for making a runnable example.
>
> It was quite a puzzle, but I tracked it down to leaking references on
> "Glyph" objects (they store little bits of descriptive information about
> characters in a font.) The leak was actually rather small, and I think
> you came across it because of the high number of iterations you were
> doing and also the largish amount of text in your plots.
>
> If you're curious, I've attached the output from valgrind's "massif"
> tool from before and after my fix. You can see from this that the leak
> was a very small percentage of the overall memory usage.
>
> The patch to fix (SVN r4918) is simple, and I'll forward it to you
> off-list. It will be included when/if we do a 0.91.3 release.
>
> Cheers,
> Mike
>
> Aaron Botnick wrote:
> > Mike,
> >
> > In response to your questions, yes, I meant to say MPL version 0.91.2.
> >
> > I believe the objects were lists and dictionaries, and they appeared to
> > be related to plotting parameters, such as those found in rcParams.
> >
> > I'm now including a gzipped tar file that includes one instance of the
> > sample data, and the input file slicer.dat, that will have the program
> > use this sample data for 512 iterations. The plots will appear in the
> > plots directory, but will be overwritten each time. I checked briefly,
> > and I believe the memory usage problem remains with this variant, as the
> > main code itself has not changed. So long as the OS doesn't cache the
> > data files, it should be nearly identical to running on the original
> data.
> >
> > Just unzip and run 'slicer_mpl.py' with the optional argument of
> slicer.dat.
> >
> > Hopefully that works for you. Thanks again.
> >
> > -- Aaron
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>

Well, this is a really good puzzle.
I think the difference in ghostscript versions is a red herring. 
Ghostscript can be used to "distill" eps files, and therefore could be 
part of the production pipeline, but only if you set the ps.usedistiller 
rcParam.
The problem in the broken .eps file you sent me was that it was 
including two STIXGeneral fonts, one with the characters produced by the 
mathtext engine, and one with the characters produced by the regular 
text engine. Since they both had the same Postscript name, the 
Postscript interpreter presumably got confused and didn't know where to 
get characters from.
Why was this happening? I have a theory. The mathtext engine looks for 
the fonts directly, since it knows they should be in the matplotlib 
installation directory, whereas the regular text engine was looking up 
the fonts through a more complex "font-finding" algorithm that finds 
fonts in a number of places on the system. It's possible (and this is a 
huge guess) that on your "broken" machine, you have the STIXGeneral font 
installed somewhere other than the matplotlib installation directory 
(~/.fonts or /usr/share/fonts or something). Matplotlib assumes that if 
two fonts have different paths that they are different fonts and *boom* 
you get two fonts with the same name in the Postscript file. All that 
is just conjecture about your situation, but I was able to reproduce it 
here by copying the STIX fonts to ~/.fonts.
I have fixed mathtext so it uses the font-finding mechanism, so that 
whenever anyone asks for "STIXGeneral", it should always get the same 
thing. That has been fixed in SVN r4928.
The problem with Ps+Type42+STIXGeneral still persists. I'm pretty 
certain this is due to the size of the font file. For that reason, 
Type3 is just a better option anyway, so I don't consider it a high 
priority -- but if you have a use case where it really matters, 
certainly let me know.
Cheers,
Mike
Bernhard Voigt wrote:
>> Well, I was able to fix the spacing problem with PDF+Type42. That has
>> now been fixed in SVN r4915 (and on the maintenance branch). It's a
>> simple patch that I'll forward to you.
> 
> Thanks, that works!
> 
>>> At home, using another gs version (8.15.0, instead of 8.15.2) also the
>>> eps is ok with ps.fonttype 3, though the one with fonttype 42 is still
>>> erroneous.
>> It's always fun when an external dependency breaks something... ;) I
>> only have the fairly old gs 7.07, and it seems to always work with type
>> 3, and sometimes break with type 42. Can you do me a favor to save me
>> the trouble of having to install a bunch of versions of ghostscript?
>> Can you send me an eps of the same plot produced through gs 8.15.0 and
>> 8.15.2? I hope that by examining the differences there will be some
>> clue as to the breakage.
> 
> Attachted are plots produced with type 3. I thought it's the viewer
> which produces the problems and gs is not involved in writing these
> files, though. Isn't the ps backend producing the ps files on its own?
> 
> Well, but somehow there is a difference in the eps files. I've on both
> machines the same matplot version, but as I said, the eps produced at
> home with type3 is ok, it's also ok viewing it a work with the newer
> gs interpreter. The other way around does not work, files produced at
> work produce errors when viewing on both machines.
> 
> Hope the files are helpflull! Bernhard
> 
> 
>> Thanks,
>> Mike
>>
>>> Thanks! Bernhard
>>>
>>>
>>> On Jan 31, 2008 4:45 PM, Michael Droettboom <md...@st...> wrote:
>>>> Can you send the source of your plot, and also your matplotlibrc file?
>>>>
>>>> Bernhard Voigt wrote:
>>>>
>>>> --
>>>>
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>> --
>>
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Alan G Isaac wrote:
> On Fri, 1 Feb 2008, Mark Bakker apparently wrote:
>> you claim that 1pt = 1/72 inch. Is that always the case? 
>> And why? How does mpl figure that out
I wrote this to help clarify some of these issues:
http://www.scipy.org/Cookbook/Matplotlib/AdjustingImageSize
> By the way, I've discovered that browser scaling
> of PNGs does not work very well (fuzzy fonts),
right, scaling rasters is never optimum.
> so
> setting both figsize and dpi correctly proves
> rather important.
exactly.
> In contrast to best practice
> for loading speed, you should not set the size
> of your IMG element.
you can set it, but make sure it matches the actual image size. That 
will get you the rendering speed, with no quality penalty.
-Chris
-- 
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...

2008年2月1日, Matthieu Brucher <mat...@gm...>:
>
>
> 4. Make sure your editor is correctly saving the file in that
> > specified encoding. This is perhaps the hardest step because editors
> > all handle it a little differently. Some editors have an option
> > somewhere to set the encoding that files are saved in. Others may
> > automatically understand the "coding" comment line in the file. (Same
> > goes for any terminal emulator you may be using for interactive
> > plotting.)
> >
> > If you can't get step 4 to work successfully, you can write Unicode
> > strings in Python using only ASCII characters using the "\u0000" escape
> > sequence.
> >
> > u"Flamb\u00e9e"
> >
> > (Here, the Unicode code point for e with accent-aigu is 00E9).
>
>
>
> I think this may be the obvious problem (I don't how to change the
> encoding in pycrust :|)
>
>
> So, following all of the above, the attached works fine for me with .eps
> > output on 0.91.2. (There were various Unicode issues in 0.90.x that
> > were fixed.) If it still doesn't work for you, please let us know.
> >
>
> I'll try this (I think the 3D stuff still works with this version, doesn't
> it ?)
>
Seems to work fine know, thanks for the tips ;)
Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Matthieu Brucher wrote:
> 
> 4. Make sure your editor is correctly saving the file in that
> specified encoding. This is perhaps the hardest step because editors
> all handle it a little differently. Some editors have an option
> somewhere to set the encoding that files are saved in. Others may
> automatically understand the "coding" comment line in the file. (Same
> goes for any terminal emulator you may be using for interactive
> plotting.)
> 
> If you can't get step 4 to work successfully, you can write Unicode
> strings in Python using only ASCII characters using the "\u0000" escape
> sequence.
> 
> u"Flamb\u00e9e"
> 
> (Here, the Unicode code point for e with accent-aigu is 00E9).
> 
> 
> 
> I think this may be the obvious problem (I don't how to change the 
> encoding in pycrust :|)
Could be. As I say, getting your editor to behave can be tricky.
> So, following all of the above, the attached works fine for me with .eps
> output on 0.91.2. (There were various Unicode issues in 0.90.x that
> were fixed.) If it still doesn't work for you, please let us know.
> 
> 
> I'll try this (I think the 3D stuff still works with this version, 
> doesn't it ?)
Yes. 0.91.x should be the same as 0.90.x in that regard.
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> 4. Make sure your editor is correctly saving the file in that
> specified encoding. This is perhaps the hardest step because editors
> all handle it a little differently. Some editors have an option
> somewhere to set the encoding that files are saved in. Others may
> automatically understand the "coding" comment line in the file. (Same
> goes for any terminal emulator you may be using for interactive plotting.)
>
> If you can't get step 4 to work successfully, you can write Unicode
> strings in Python using only ASCII characters using the "\u0000" escape
> sequence.
>
> u"Flamb\u00e9e"
>
> (Here, the Unicode code point for e with accent-aigu is 00E9).
I think this may be the obvious problem (I don't how to change the encoding
in pycrust :|)
So, following all of the above, the attached works fine for me with .eps
> output on 0.91.2. (There were various Unicode issues in 0.90.x that
> were fixed.) If it still doesn't work for you, please let us know.
>
I'll try this (I think the 3D stuff still works with this version, doesn't
it ?)
Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Unicode in Python is tricky. It is explained in gory detail here:
 http://www.amk.ca/python/howto/unicode
But to save you the trouble of reading the whole thing, unless you're an 
i18n geek like me, here's my list of recommendations to (somewhat) 
reliably get non-ASCII characters to work in Python. There are other 
ways, (and people tend to have their own opinions about this, mostly 
based on the capabilities of their editors).
 1. "Non-ASCII" means any codepoint that is greater than 127. Your 
local encoding may have characters with accents in the range 128-255, 
but that is *not* ASCII.
 2. Always use Unicode literals for anything that contains non-ASCII 
characters (by prefixing the literal with a 'u'). It is never a good 
idea to put non-ASCII characters in a regular 8-bit Python string -- 
they do not "remember" their encoding, and the application has no way to 
know how to interpret it.
 3. Always declare an encoding at the top of the file, e.g.:
	# -*- coding: utf-8 -*-
 (I like utf-8 for generality, but you could use any of the 
encodings that Python understands, see here: 
http://docs.python.org/lib/standard-encodings.html)
 4. Make sure your editor is correctly saving the file in that 
specified encoding. This is perhaps the hardest step because editors 
all handle it a little differently. Some editors have an option 
somewhere to set the encoding that files are saved in. Others may 
automatically understand the "coding" comment line in the file. (Same 
goes for any terminal emulator you may be using for interactive plotting.)
If you can't get step 4 to work successfully, you can write Unicode 
strings in Python using only ASCII characters using the "\u0000" escape 
sequence.
	u"Flamb\u00e9e"
(Here, the Unicode code point for e with accent-aigu is 00E9).
So, following all of the above, the attached works fine for me with .eps 
output on 0.91.2. (There were various Unicode issues in 0.90.x that 
were fixed.) If it still doesn't work for you, please let us know.
Cheers,
Mike
Matthieu Brucher wrote:
> No problem with the png backend.
> 
> I tried with Latex for the accent, but it didn't work :
> Traceback (most recent call last):
> File "<input>", line 1, in <module>
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/pyplot.py", 
> line 265, in draw
> get_current_fig_manager().canvas.draw()
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
> line 953, in draw
> self.figure.draw(self.renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/figure.py", 
> line 612, in draw
> for a in self.axes: a.draw(renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axes.py", 
> line 1342, in draw
> a.draw(renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", 
> line 593, in draw
> tick.draw(renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", 
> line 170, in draw
> if self.label1On: self.label1.draw(renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", 
> line 775, in draw
> Text.draw(self, renderer)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", 
> line 327, in draw
> self._fontproperties, angle)
> File 
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/backend_bases.py", 
> line 383, in draw_tex
> raise NotImplementedError
> 
> I just did :
> 
> import pylab as pl
> pl.plot([1, 2, 3], [1, 2, 3])
> pl.xlabel('éè')
> pl.show()
> 
> and the ps file is corrupted :(
> 
> Matthieu
> 
> 2008年2月1日, Michael Droettboom <md...@st... <mailto:md...@st...>>:
> 
> Can you provide an example of your code? Often, it is a matter of
> configuring/using Python correctly to indicate accents. Is the problem
> only with EPS or other backends as well?
> 
> Cheers,
> Mike
> 
> 
> Matthieu Brucher wrote:
> > Hi,
> >
> > I'm trying to export a MAtplotlib figure which has some axes labels,
> > such as 'coût'.
> > The problème is that the generated eps is corrupted because of these
> > accents. Is there a way to generate an acceptable eps file ?
> >
> > Matthieu
> > --
> > French PhD student
> > Website : http://matthieu-brucher.developpez.com/
> > Blogs : http://matt.eifelle.com and
> http://blog.developpez.com/?blog=92
> > LinkedIn : http://www.linkedin.com/in/matthieubrucher
> >
> >
> 
> >
> ------------------------------------------------------------------------
> >
> >
> -------------------------------------------------------------------------
> > 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/
> >
> >
> >
> ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 
> 
> 
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Some additional information : it does not work with the pdf backend and wit=
h
the svg one, the accents are corrupted (I tried to export utf8 encoded
labels).
I'm using pycrust, BTW. But I don't know how to change the default encoding
(the display is correct but not the saved image).
Matthieu
2008年2月1日, Matthieu Brucher <mat...@gm...>:
>
> No problem with the png backend.
>
> I tried with Latex for the accent, but it didn't work :
> Traceback (most recent call last):
> File "<input>", line 1, in <module>
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/pyplot.py",
> line 265, in draw
> get_current_fig_manager().canvas.draw()
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/backends/bac=
kend_wx.py",
> line 953, in draw
> self.figure.draw(self.renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/figure.py",
> line 612, in draw
> for a in self.axes: a.draw(renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axes.py", li=
ne
> 1342, in draw
> a.draw(renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", li=
ne
> 593, in draw
> tick.draw(renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", li=
ne
> 170, in draw
> if self.label1On: self.label1.draw(renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", li=
ne
> 775, in draw
> Text.draw(self, renderer)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", li=
ne
> 327, in draw
> self._fontproperties, angle)
> File
> "/home/brucher/local//lib/python2.5/site-packages/matplotlib/backend_base=
s.py",
> line 383, in draw_tex
> raise NotImplementedError
>
> I just did :
>
> import pylab as pl
> pl.plot([1, 2, 3], [1, 2, 3])
> pl.xlabel('=E9=E8')
> pl.show()
>
> and the ps file is corrupted :(
>
> Matthieu
>
> 2008年2月1日, Michael Droettboom <md...@st...>:
> >
> > Can you provide an example of your code? Often, it is a matter of
> > configuring/using Python correctly to indicate accents. Is the problem
> > only with EPS or other backends as well?
> >
> > Cheers,
> > Mike
> >
> >
> > Matthieu Brucher wrote:
> > > Hi,
> > >
> > > I'm trying to export a MAtplotlib figure which has some axes labels,
> > > such as 'co=FBt'.
> > > The probl=E8me is that the generated eps is corrupted because of thes=
e
> > > accents. Is there a way to generate an acceptable eps file ?
> > >
> > > Matthieu
> > > --
> > > French PhD student
> > > Website : http://matthieu-brucher.developpez.com/
> > > Blogs : http://matt.eifelle.com and
> > http://blog.developpez.com/?blog=3D92
> > > LinkedIn : http://www.linkedin.com/in/matthieubrucher
> > >
> > >
> >
> > >
> > -----------------------------------------------------------------------=
-
> > >
> > >
> > -----------------------------------------------------------------------=
--
> > > 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/
> > >
> > >
> > >
> > -----------------------------------------------------------------------=
-
> > >
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> > --
> > Michael Droettboom
> > Science Software Branch
> > Operations and Engineering Division
> > Space Telescope Science Institute
> > Operated by AURA for NASA
> >
>
>
>
> --
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=3D92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
>
--=20
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=3D92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

No problem with the png backend.
I tried with Latex for the accent, but it didn't work :
Traceback (most recent call last):
 File "<input>", line 1, in <module>
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/pyplot.py",
line 265, in draw
 get_current_fig_manager().canvas.draw()
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/backends/backe=
nd_wx.py",
line 953, in draw
 self.figure.draw(self.renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/figure.py",
line 612, in draw
 for a in self.axes: a.draw(renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/axes.py", line
1342, in draw
 a.draw(renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", line
593, in draw
 tick.draw(renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/axis.py", line
170, in draw
 if self.label1On: self.label1.draw(renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", line
775, in draw
 Text.draw(self, renderer)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/text.py", line
327, in draw
 self._fontproperties, angle)
 File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/backend_bases.=
py",
line 383, in draw_tex
 raise NotImplementedError
I just did :
import pylab as pl
pl.plot([1, 2, 3], [1, 2, 3])
pl.xlabel('=E9=E8')
pl.show()
and the ps file is corrupted :(
Matthieu
2008年2月1日, Michael Droettboom <md...@st...>:
>
> Can you provide an example of your code? Often, it is a matter of
> configuring/using Python correctly to indicate accents. Is the problem
> only with EPS or other backends as well?
>
> Cheers,
> Mike
>
>
> Matthieu Brucher wrote:
> > Hi,
> >
> > I'm trying to export a MAtplotlib figure which has some axes labels,
> > such as 'co=FBt'.
> > The probl=E8me is that the generated eps is corrupted because of these
> > accents. Is there a way to generate an acceptable eps file ?
> >
> > Matthieu
> > --
> > French PhD student
> > Website : http://matthieu-brucher.developpez.com/
> > Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=3D=
92
> > LinkedIn : http://www.linkedin.com/in/matthieubrucher
> >
> >
>
> > -----------------------------------------------------------------------=
-
> >
> >
> -------------------------------------------------------------------------
> > 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/
> >
> >
> > -----------------------------------------------------------------------=
-
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
--=20
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=3D92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Can you provide an example of your code? Often, it is a matter of 
configuring/using Python correctly to indicate accents. Is the problem 
only with EPS or other backends as well?
Cheers,
Mike
Matthieu Brucher wrote:
> Hi,
> 
> I'm trying to export a MAtplotlib figure which has some axes labels, 
> such as 'coût'.
> The problème is that the generated eps is corrupted because of these 
> accents. Is there a way to generate an acceptable eps file ?
> 
> Matthieu
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I'm trying to export a MAtplotlib figure which has some axes labels, such a=
s
'co=FBt'.
The probl=E8me is that the generated eps is corrupted because of these
accents. Is there a way to generate an acceptable eps file ?
Matthieu
--=20
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=3D92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

On Fri, 1 Feb 2008, Stephen George wrote:
> bit confused what your asking.
> are you looking for the pylab API savefig
Stephen/Alan/Chloe:
 Yes, it turns out that I am.
> or you asking how to convert your variable+.png into a filename?
> is your variable a number?, string?
 The variable is a string, and I do want to use it as a file name.
> pylab.savefig('%s.png'% curVar)
 I wasn't aware of the savefig() function, and was trying to use save()
instead. As soon as I made that change, it worked.
Thanks for the lesson!
Rich
-- 
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

Mark Bakker wrote:
> Alan -
> 
> You started a discussion about dpi on the figures.
> Yet here you claim that 1pt = 1/72 inch.
> Is that always the case?
Barring any bugs, yes.
> And why? How does mpl figure that out, if there are also different dpi 
> settings?
The conversion from points to pixels is simply "dpi * points / 72.0".
Cheers,
Mike
> The plot thickens...
> 
> Mark
> 
> 
> Alan Isaac wrote: 
> 
> 
> Note: 1pt = 1/72 inch
> 
> hth,
> Alan Isaac
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, 1 Feb 2008, Mark Bakker apparently wrote:
> you claim that 1pt = 1/72 inch. Is that always the case? 
> And why? How does mpl figure that out
Based on the discussion for far,
I assume it works like this.
(figsize in inches) * dpi = (size in pixels)
So if you draw a line 72 points long,
which is 1" in figsize units,
then it will display as being dpi pixels in length.
So for PNG, for example, figsize is a kind of
Platonic concept, which we view dimly through
the actual size of our figure.
By the way, I've discovered that browser scaling
of PNGs does not work very well (fuzzy fonts), so
setting both figsize and dpi correctly proves
rather important. In contrast to best practice
for loading speed, you should not set the size
of your IMG element. Or so it seems.
fwiw,
Alan

Mark Bakker wrote:
> Alan -
> 
> You started a discussion about dpi on the figures.
> Yet here you claim that 1pt = 1/72 inch.
> Is that always the case?
Yes, I that's *by definition* always the case !
pt is a point - not a dot or a pixel !!!
"Point" is a unit of measurement used in typography that is equal to 
1/72 inch. It is used primarily for representing the height of 
characters and the amount of space between lines, also known as leading.
 --> see http://support.microsoft.com/kb/76388
Manuel
> And why? How does mpl figure that out, if there are also different dpi
> settings?
> The plot thickens...
> 
> Mark
> 
> 
>> Alan Isaac wrote:
> 
> 
>> Note: 1pt = 1/72 inch
>>
>> hth,
>> Alan Isaac
>>
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

New version is available now. Just select matplotlib component from Boa
pallete and plot any number of different plots as easy as with Pylab. See
runtime sample. My e-mail is kh...@in... If you are interested, please,
write me. It costs 50ドル. Igor V. Khromushin
http://www.nabble.com/file/p15221924/runtimesample1.jpg 
-- 
View this message in context: http://www.nabble.com/Easy-Embedding-of-Matplotlib-in-wx-appls-module-%2B-Boa-constructor-plug-in-for-Matplotlib-tp15221924p15221924.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Alan -
You started a discussion about dpi on the figures.
Yet here you claim that 1pt = 1/72 inch.
Is that always the case?
And why? How does mpl figure that out, if there are also different dpi
settings?
The plot thickens...
Mark
> Alan Isaac wrote:
> Note: 1pt = 1/72 inch
>
> hth,
> Alan Isaac
>

Hi all,
sorry for the quick cross-post, but I know that many mpl users rely on
the ipython -pylab support for interactive work.
This is a call for testing from current SVN of anyone who uses ipython
with the GUI thread support, whether via -pylab or directly via one of
the -Xthread options.
For a long time I've known that this code was subject to possible
deadlocks, having seen it go nuts on me on occasion, but I'd never
been able to track down the exact source of the race conditions
causing it (I'm not an expert in threads at all). In
http://ipython.scipy.org/ipython/ipython/ticket/210
http://ipython.scipy.org/ipython/ipython/ticket/212
a very helpful analysis and solution code was provided by Marc. I've
applied his fixes to current SVN, and with my testing so far I've been
unable to get any more deadlocks or crashes, so this looks great, and
his analysis looks very sound to me. In particular, it makes proper
use of a re-entrant lock which I'd originally tried to use but given
up on, due to having used it incorrectly (though I knew it should be
the right tool). I'd just left a comment noting the issue, which
Marc's fixes now address.
It would be great if any of you who relies on the GUI thread support
could test this, since this threaded code is subtle and has a long
history of hard to trigger but annoying bugs. You can run it from
SVN. In a few minutes I'll finish uploading test builds as well to
http://ipython.scipy.org/dist/testing/
if you prefer to install from there.
I'd appreciate feedback, either of improvements or of any remaining misbehavior.
Thanks, especially to Marc for helping us make progress on this
long-standing nag.
Cheers,
f

Eric:
I have never seen any software which dealt with non uniform DPI 
settings, although that is always a possibility. And all the displays I 
have ever worked on/with have been the same for both H and V. ( I am a 
display engineer with over 25 years experience in CRT displays and a bit 
in flat panel). From what I have seen, the RGB trio in any display is 
set up so that the horizontal pitch is the same as the vertical pitch. 
In a flat panel the R, G and B are 3 times taller than they are wide so 
that when you place R, G and B together they form a square. I don't 
think that Matplotlib or Alan needs to worry about anything outside 
those boundaries.
Wayne
Eric Firing wrote:
> John Hunter wrote:
> 
>> On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote:
>>
>> 
>>> Screens vary. The screen on my laptop has about 130 dpi. Desktop flat
>>> panels will usually have a smaller value than that. For example, an old
>>> "15-inch" flat panel with 1024/768 pixels is actually about 12 inches
>>> wide, so dpi=85. The mpl default 'figure.dpi' of 80 is low; I doubt
>>> 
>> And it is not unusual to have a different DPI in the horizontal and
>> vertical directions. In order to support true physical sizes on the
>> screen, we would need to support different dpis in the two directions.
>> 
>
> Does any other software actually do this? I have never seen anything 
> with more than a single dpi setting. What is an example of a display 
> with non-square pixels? And how non-square are they? I suspect this is 
> not something that Alan really needs to worry about.
>
> Eric
>
> -------------------------------------------------------------------------
> 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/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 

Hi Rich,
bit confused what your asking.
are you looking for the pylab API savefig
http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-savefig
or you asking how to convert your variable+.png into a filename?
is your variable a number?, string?
for count in range(3):
 count = count +1
 fname = 'MyPlot_%d.png' %count
 print fname
mystr = 'MyFirstPlot'
fname = '%s.png' % mystr
print fname
results in
 >python -u "test.py"
MyPlot_1.png
MyPlot_2.png
MyPlot_3.png
MyFirstPlot.png
 >Exit code: 0
pylab.savefig('%s.png'% curVar)
 or
pylab.savefig('%d.png'% curVar)
Does anything here help?
Steve
Rich Shepard wrote:
> I want to save plots programmatically, using a variable + .png as the
> filename. I don't see an example of the proper syntax, and my
> trial-and-error approach hasn't yielded a solution, either.
>
> If I want to write
>
> 	pylab.save(curVar.png)
>
> where 'curVar' is a variable assigned programmatically, how do I correctly
> write it?
>
> Rich
>
> 

On 2008年1月31日, Rich Shepard apparently wrote:
> If I want to write
> 	pylab.save(curVar.png)
> where 'curVar' is a variable assigned programmatically, how do I correctly 
> write it? 
Use string concatenation:
curVar+'.png'
<URL:http://docs.python.org/tut/node5.html#SECTION005120000000000000000>
hth,
Alan Isaac

 I want to save plots programmatically, using a variable + .png as the
filename. I don't see an example of the proper syntax, and my
trial-and-error approach hasn't yielded a solution, either.
 If I want to write
 	pylab.save(curVar.png)
where 'curVar' is a variable assigned programmatically, how do I correctly
write it?
Rich
-- 
Richard B. Shepard, Ph.D. | Integrity Credibility
Applied Ecosystem Services, Inc. | Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

Hello Fernando,
>> <type 'exceptions.AttributeError'>: 'module' object has no attribute
>> 'ArrayType'
>>
>> maybe some of the IPython power users can give me a hint why this
>> happes. [1]
> 
> Very strange. I can't reproduce it here (on gutsy, but running
> ipython from my own tree). What's odd is this:
> 
> In [1]: import Numeric
> 
> In [2]: print Numeric.ArrayType
> <type 'array'>
> 
> 
> So Numeric *most definitely* has an ArrayType member. Try doing the
> same as I did, also showing us whether you started ipython with -pylab
> or not. There may be something odd about your Numeric installation.
> Also do this:
> 
> In [3]: Numeric?
> Type: module
> Base Class: <type 'module'>
> Namespace: Interactive
> File: /usr/lib/python2.5/site-packages/Numeric/Numeric.py
> 
> [etc]
> 
> It's possible that you have in your path a file called Numeric.py
> which is not the 'real' Numeric module. This would explain your
> problem and why nobody else sees it.
> 
> Cheers,
> 
> f
*** my output ***
$ ipython
Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
Type "copyright", "credits" or "license" for more information.
IPython 0.8.1 -- An enhanced Interactive Python.
? -> Introduction to IPython's features.
%magic -> Information about IPython's 'magic' % functions.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
In [1]: import Numeric
In [2]: print Numeric.ArrayType
---------------------------------------------------------------------------
<type 'exceptions.AttributeError'> Traceback (most recent call last)
/home/timmie/<ipython console> in <module>()
<type 'exceptions.AttributeError'>: 'module' object has no attribute 
'ArrayType'
In [3]: Numeric?
Type: module
Base Class: <type 'module'>
String Form: <module 'Numeric' from 
'/home/timmie/development/python/modules/modules_library/Numeric/__init__.pyc'>
Namespace: Interactive
File: 
/home/timmie/development/python/modules/modules_library/Numeric/__init__.py
Docstring:
 <no docstring>
In [4]:
*** end code ***
=> You were absolutely right:
I had another Numeric package install in my PYTHONPATH. It overwrode the 
system package at:
/usr/lib/python2.5/site-packages/Numeric/Numeric.py
I just deleted 
/home/timmie/development/python/modules/modules_library/Numeric and now 
everything to goes nice. I can use my Ipython again with numerics ;-)
Well, I guess the problem arose from the a time when I didn't have 
network access.
I just threw python modules from the net into my PYTHONPATH without 
using the Synaptic package manager.
Nice that this is now solved. Thanks for your quick answer and help!
Kind regards,
Timmie