matplotlib-users Mailing List for matplotlib (Page 14)

Included is a patch to change the behavior when legend() is called with numpoints less than or equal to 0. Currently if one makes such a call, some cryptic error messages are printed out and the plot is not generated.

The included patch produces a warning, and defaults to using numpoints = 4, so the plot is actually made.

Paul Novak

---
--- legend.py	2008-02-01 19:14:24.000000000 -0600
+++ legend.py	2008-02-01 19:13:55.000000000 -0600
@@ -166,6 +166,12 @@
 
         self._loc = loc
 
+        if self.numpoints <= 0:
+            warnings.warn('legend() called with numpoints = %d. '
+                          'Default to numpoints = 4 because numpoints must be greater than zero.' \
+                          % (self.numpoints))
+            self.numpoints = 4
+
         self.legendPatch = Rectangle(
             xy=(0.0, 0.0), width=0.5, height=0.5,
             facecolor='w', edgecolor='k',

When using the PostScript backend, and plotting several lines with the same call to plot (or when plotting a LineCollection), kwargs are applied to the first line only, and not to every line.

Included is a minimal script that exhibits this problem. The saved figure shows only one thick red line where we would expect two such lines.

Paul Novak

#!/usr/bin/env python

import matplotlib
matplotlib.use('PS')
from pylab import *

x = arange(0.0, 5.0)
y = 2 * x
plot(x, x, x, y, color='red', linewidth = 5)

savefig('image')

show()

Rich Shepard wrote:
> On Fri, 1 Feb 2008, Eric Firing wrote:
> 
>> What changed is that I added a warning where previously there was only a
>> silent error--the matplotlib.use command was being ignored. Sometimes
>> this (ignoring the command) is harmless, but it is never the user's intent
>> and in some cases it can cause puzzling problems. It often occurs when a
>> script or module does "from pylab import *" or "import pylab as P", and
>> then later "import matplotlib; matplotlib.use('Agg')". In this example,
>> the user intends to make plots non-interactively, writing them to files,
>> but the whole gui machinery for the default backend (e.g., gtkagg or wxagg
>> or tkagg) is imported unintentionally.
> 
> Eric,
> 
>    Thanks for the explanation. And you bring up another issue that I have:
> the most appropriate way to generate non-interactive plots, written to
> files, for inclusion in a ReportLab report. Do I want to use pylab for this,
> plots embedded in wx, or something else?

If you are generating plots non-interactively--that is, entirely in a 
script, so you don't need to see the plot on the screen to fiddle with 
it--then use a non-interactive backend.  WxAgg, TkAgg, GtkAgg, QtAgg, 
etc. are needed only if you are working interactively.  They don't 
necessarily hurt otherwise, but they don't help.

I have taken a quick look at the ReportLab documentation, and it looks 
like you are stuck with using PIL to import png files. (This means using 
the Agg backend.) If what you are plotting is image-like, this is not so 
bad, but it is not great in any case.  It means things like text in your 
plot (axes ticks, labels, etc.) that should be getting into your final 
pdf in native form will instead get in as bit patterns, and this is bad 
for both quality and file size.  Same for lines; it would be much better 
to generate vector graphics directly in your report.  It would be nice 
to have something like a pdf-to-reportlab or svg-to-reportlab code 
generator, so you could use the pdf or svn matplotlib backend, and keep 
vectors as vectors.

If your matplotlib plots can be on separate pages, then you could use 
the pdf backend to generate those pages, and use pdftk to insert them 
among the pages generated by ReportLab.

Whether to use pylab is an entirely separate issue; it is a matter of 
programming style.  The usual advice would be to use matplotlib.pyplot 
for a very few functions (figure, close, maybe a few others) and then 
use object-oriented style--that is, object method calls instead of 
functions--for everything else.  There is nothing wrong with sticking 
with pylab or pyplot functions, though--they work fine.

> 
>    I need to get this module running properly so I am focusing on really
> understanding how to use matplotlib to produce what we need.
> 
>> One way to find out where the warning is coming from is to invoke your script 
>> as
>>
>> python -Werror myscript.py
>>
>> which will turn the warning into an error and thereby trigger an exception 
>> traceback.
> 
>    OK. Tomorrow morning I'll do this.
> 
>> What this will *not* tell you is where the *earlier* call to
>> matplotlib.use() is occurring. To find it you will have to trace back

Note the following three lines carefully:
>> through your application, looking for the first place where pylab,
>> matplotlib.pyplot, or matplotlib.backends is imported, or the first
>> explicit use of matplotlib.use(), whichever is earliest.
Where and when matplotlib itself is imported doesn't matter--it is the 
events listed above that are relevant to your question.

Eric

> 
>    There are two modules in which pylab is used: reports.py and functions.py.
> The former calls specific matplotlib functions in the latter.
> 
>    On the other hand, matplotlib is imported in several modules. Perhaps
> that's the problem. I'll check this tomorrow, too.
> 
> Thanks,
> 
> Rich
> 

On Fri, 1 Feb 2008, Eric Firing wrote:

> One way to find out where the warning is coming from is to invoke your script 
> as
>
> python -Werror myscript.py

Eric,

   That did the trick. Two modules needed to have the backend specification
commented out.

Many thanks,

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

On Fri, 1 Feb 2008, Eric Firing wrote:

> What changed is that I added a warning where previously there was only a
> silent error--the matplotlib.use command was being ignored. Sometimes
> this (ignoring the command) is harmless, but it is never the user's intent
> and in some cases it can cause puzzling problems. It often occurs when a
> script or module does "from pylab import *" or "import pylab as P", and
> then later "import matplotlib; matplotlib.use('Agg')". In this example,
> the user intends to make plots non-interactively, writing them to files,
> but the whole gui machinery for the default backend (e.g., gtkagg or wxagg
> or tkagg) is imported unintentionally.

Eric,

   Thanks for the explanation. And you bring up another issue that I have:
the most appropriate way to generate non-interactive plots, written to
files, for inclusion in a ReportLab report. Do I want to use pylab for this,
plots embedded in wx, or something else?

   I need to get this module running properly so I am focusing on really
understanding how to use matplotlib to produce what we need.

> One way to find out where the warning is coming from is to invoke your script 
> as
>
> python -Werror myscript.py
>
> which will turn the warning into an error and thereby trigger an exception 
> traceback.

   OK. Tomorrow morning I'll do this.

> What this will *not* tell you is where the *earlier* call to
> matplotlib.use() is occurring. To find it you will have to trace back
> through your application, looking for the first place where pylab,
> matplotlib.pyplot, or matplotlib.backends is imported, or the first
> explicit use of matplotlib.use(), whichever is earliest.

   There are two modules in which pylab is used: reports.py and functions.py.
The former calls specific matplotlib functions in the latter.

   On the other hand, matplotlib is imported in several modules. Perhaps
that's the problem. I'll check this tomorrow, too.

Thanks,

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

On Jan 31, 2008 6:03 AM, Thomas Tanner <ta...@tu...> wrote:
> Hi,
> I'd like to have figure with 3 (or 4) plots having different scales
> but sharing the same x-axis.
> Basically I want an extension of the twinx command (see, e.g,
> two_scales.py demo).
> I'm using 0.91.2svn on MacOSX10.5.1 from http://trichech.us/?page_id=5

[snip]

> The 4th plot overwrites the ylim of the 1st plot (bug?).
> Is there a limit of 3 axes per figure?
> The ylim of plot4 is still ignored.
> Why do I have to add the axes a1 and a4 the main axes to make them visible?

I'm working on an app that has 8 axes per figure (X1, X2, Y1 ... Y4)
and it works fine.  Well, the MPL bits do.

One of the unexpected things that we had to do in order to get the
multiple plots to work as expected was to ensure that each additional
subplot had its own label.  MPL has some 'helper' code that tries to
consolidate the axes so that if you create two axes with identical
parameters, you only end up with one axes object (I think -- someone
more knowledgeable can fill you in on the details).

Now, we do things using the API rather than using pylab, some I'm not
entirely certain (and haven't tested it) but I think that the pylab
command 'axes' has an optional argument of 'label', which you should
set to be a unique string for each subplot.

I've only scanned through your code, and I'm not at all familiar with
the pylab syntax, but I'm puzzled that you haven't used twinx (or in
API parlance, sharex) anywhere.  Regardless, the API code for
overlaying subplots is of the form:

figure.add_axes(axes1.get_position(), sharex=axes1, frameon=False,
label='someUniqueString')

Hope this helps,
Anthony.

Rich Shepard wrote:
>    I just upgraded my Slackware-11.0 workstation from matplotlib-0.90.1 to
> -0.91.2. When I now start my application I see this:
> 
> /usr/lib/python2.4/site-packages/matplotlib/__init__.py:753: UserWarning:
> This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
> 
>    warnings.warn(_use_error_msg)
> 
>    I don't know to which matplotlib.use() call the message refers. At the top
> of the module in which matplotlib is used I have
>                             matplotlib.use('WXAgg')
> 
> and the above warning did not appear with the prior version of the library.
> 
>    Please help me to understand what changed, and how to fix the change so
> the warning no longer appears.

What changed is that I added a warning where previously there was only a 
silent error--the matplotlib.use command was being ignored.  Sometimes 
this (ignoring the command) is harmless, but it is never the user's 
intent and in some cases it can cause puzzling problems.  It often 
occurs when a script or module does "from pylab import *" or "import 
pylab as P", and then later "import matplotlib; matplotlib.use('Agg')". 
In this example, the user intends to make plots non-interactively, 
writing them to files, but the whole gui machinery for the default 
backend (e.g., gtkagg or wxagg or tkagg) is imported unintentionally.

One way to find out where the warning is coming from is to invoke your 
script as

python -Werror myscript.py

which will turn the warning into an error and thereby trigger an 
exception traceback.

What this will *not* tell you is where the *earlier* call to 
matplotlib.use() is occurring. To find it you will have to trace back 
through your application, looking for the first place where pylab, 
matplotlib.pyplot, or matplotlib.backends is imported, or the first 
explicit use of matplotlib.use(), whichever is earliest.

Eric

   I just upgraded my Slackware-11.0 workstation from matplotlib-0.90.1 to
-0.91.2. When I now start my application I see this:

/usr/lib/python2.4/site-packages/matplotlib/__init__.py:753: UserWarning:
This call to matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

   warnings.warn(_use_error_msg)

   I don't know to which matplotlib.use() call the message refers. At the top
of the module in which matplotlib is used I have
                            matplotlib.use('WXAgg')

and the above warning did not appear with the prior version of the library.

   Please help me to understand what changed, and how to fix the change so
the warning no longer appears.

Thanks,

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

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
>