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
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
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 i
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
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 pu
On Jan 31, 2008 6:03 AM, Thomas Tanner <[EMAIL PROTECTED]> 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 f
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 back
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;
mat
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 <[EM
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
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 t
2008/2/1, Matthieu Brucher <[EMAIL PROTECTED]>:
>
>
>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 tha
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 sav
>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 understa
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
Some additional information : it does not work with the pdf backend and with
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/
No problem with the png backend.
I tried with Latex for the accent, but it didn't work :
Traceback (most recent call last):
File "", line 1, in
File
"/home/brucher/local//lib/python2.5/site-packages/matplotlib/pyplot.py",
line 265, in draw
get_current_fig_manager().canvas.draw()
File
"/
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
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.c
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
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 pix
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,
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 t
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 [EMAIL PROTECTED] If you are interested, please,
write me. It costs $50. Igor V. Khromushin
http://www.nabble.com/file/p15
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 Is
25 matches
Mail list logo
