matplotlib-users Mailing List for matplotlib (Page 6)

Hi all,

what could be a simple way when I have 'seconds' as data to
display them as %H:%M:%S on the x-axes?

many thanks
marco
-- 
   (o_  It rocks: LINUX + Command-Line-Interface
   //\                           GPG: 0x59D90F4D
   V_/_                     http://www.calmar.ws

Thanks a lot, Ben!!!

With using the mplot3d/pbaspect branch, my plot shows exactly what i asked
for a few hours(!) ago. Nothing ugly here :)
I'll keep track of that branch and can at least contribute by testing.

Richard

2011/6/9 Benjamin Root <ben...@ou...>

>
>
> On Thu, Jun 9, 2011 at 10:13 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Thu, Jun 9, 2011 at 6:25 AM, Richard Hofmeister <
>> ric...@io...> wrote:
>>
>>> Hello mplot3d specialists,
>>>
>>> I would like to change the aspect ratio of the 3d axes similar to
>>> matlab's functionality with daspect() or the 'dataaspectratio' property of
>>> 3d-axes.
>>> In the end, the x-y-plane should be non-square due to different lengths
>>> (not range) of the x and y axis (i know that i can use the aspect property
>>> of the axes to set the x-z/y-z aspect ratio).
>>>
>>> There is also the package "scitools", which provides all the matlab-3d
>>> functions including daspect via a VTK-backend; that would be my next try.
>>>
>>> For the simple 3d-plotting without fancy shading, i would like to stick
>>> to mplot3d:
>>> Is it possible to change the axis lengths/aspect ratios independently?
>>>
>>> Richard
>>>
>>>
>> Richard,
>>
>> Good question.  I have never thought about such a feature for mplot3d.
>> Looking back at the code, it does not appear to be feasible to do in its
>> current state, as the code seems to assume that the 3d grid is a constructed
>> from a unit cube.  However, I will see if I can add aspect multipliers to
>> the point calculation and get arbitrary aspects.  Maybe I can get that
>> feature added into the upcoming 1.1.0 release.
>>
>> Ben Root
>>
>>
> Richard,
>
> I took a look at how this might be implemented.  There would have to be
> some extra work to make the plots look right when experiencing changes in
> aspect.  I first tried an implementation of just the plot box aspect ratio
> (pbaspect) as a member variable of the axes object.  It will probably turn
> into a property so that I can link it with a daspect value.  Also, the
> values should be normalized to 1, unless you want to see some interesting
> shrinkage/growth of your plot area.
>
> Try my branch here:
> https://github.com/WeatherGod/matplotlib/tree/mplot3d/pbaspect
>
> After building that branch, try the following script (shamelessly adapted
> from some Matlab help pages for pbaspect and daspect).
>
> import matplotlib.pyplot as plt
> from mpl_toolkits.mplot3d import Axes3D
> import numpy as np
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
>
> x, y = np.mgrid[-2:2:.2, -2:2:.2]
> z = x * np.exp(-x**2 - y**2)
> ax.plot_surface(x, y, z, rstride=1, cstride=1)
> ax.pbaspect = [1.0, 1.0, 0.25]
> plt.show()
>
> While this will squash the z-axis nicely, it does not force the z-ticks to
> be pruned, so it gets a little ugly.  However, the axis ticks can be changed
> manually.  Also, with some of my other changes coming soon, it should be
> possible for the Axes3D object to automatically adjust the spacing of the
> tick labels so that it is not impacted by the changes in aspect ratio in the
> perpendicular direction (i.e. - the x and y tick labels are closer to the
> axis due to the z-axis scaling).
>
> Keep an eye on that branch as I work to improve this feature, and feel free
> to contribute to it as well!
>
> Ben Root
>

On 06/09/2011 09:45 AM, Benjamin Root wrote:
>
>
> On Tue, Jun 7, 2011 at 5:01 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 06/07/2011 11:46 AM, Benjamin Root wrote:
>      > On Saturday, June 4, 2011, Eric Firing<ef...@ha...
>     <mailto:ef...@ha...>>  wrote:
>      >>
>      >>
>      >>
>     https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
>      >>
>      >> Eric, Ben,
>      >>
>      >> See if the section "What is interactive mode" makes sense to
>     you.  I have just added it to a feature branch (which includes some
>     other faq madifications, mainly moving the backend section from
>     installation to usage), but have not yet generated a pull request.
>       It doesn't go into every detail, or into the underlying machinery.
>       It is intended to provide just enough understanding to clear up
>     user-level confusion about interactive mode, show, and draw, and let
>     most relatively new users get on with their work.
>      >>
>      >> Eric
>      >>
>      >
>      > Eric,
>      >
>      > I see where you are going with this, and this is valuable information
>      > to include in the docs. However, the interactive mode and backend
>     info
>      > doesn't seem to fit properly with everything else on the page.  I am
>
>     I don't see why not.  A FAQ is a place for answers to questions, and
>     this is the usage section of the FAQ, so I don't see any inherent reason
>     why information about backends and interactive mode, both of which
>     involve mpl usage, can't go there.  There may be better places, to which
>     the FAQ could refer, but I think the FAQ is better than nothing.  I
>     moved the backend piece from the installation part of the FAQ, where it
>     *really* didn't belong.  (And the remaining installation part is also an
>     out-of-date worm jar.)
>
>
> I am looking at doc/faq/installing_faq.rst on your branch, and I can't
> tell what is out-of-date (although the Mac part might be, I don't
> know).  If you are referring to doc/users/installing.rst, that should
> have been removed in the big set of commits I made recently when I
> merged from v1.0.x-maint to master (the INSTALL file is now used in
> master for the installation docs).

Ben,

I am referring to doc/faq/installing_faq.rst, and I am mainly concerned 
about the OS-X section.  The version references are clearly out of date; 
as for the rest, I have no idea what actually works and should be 
recommended.  Attempts have been made elsewhere in mpl to update and 
clarify the OS-X build and install situation, but I don't think any of 
that is reflected in this faq section, and I would not be surprised if 
there are other places in the overall mpl tree where OS-X confusion 
still lurks.  Certainly the mailing list indicates that OS-X 
installation and building has been a frequent sore point.  Although I 
have built and installed mpl on an OS-X machine, I don't normally use 
one, and I certainly don't understand all the arcane variables and 
variations.

In OS-X and elsewhere I would also raise the question: does easy-install 
have a high enough success rate with mpl that it should be included as a 
reasonable option?  Or should its use for mpl be discouraged? I don't 
know the answer, and have never tried easy-install with mpl, but in 
general I don't trust it.  Too much behind-the-scenes magic.

And the users/installing.rst has problems, too, in addition to the 
general problem of information about building and installing being 
scattered among the users section, the faq, INSTALL, make.osx, and 
setup*.  Small example: installation requirements are listed under the 
heading "Build requirements".

Progress is going to have to be incremental; I doubt that anyone will 
have the time to go through the whole system and really clean everything 
up in one pass.

I suggest, if you don't mind, that I go ahead and merge my branch into 
maint (and from there, master), and then the next increment, whether by 
you, me, or someone else, can be in a new branch, and the process can be 
repeated.

Eric

>
> The problem I do see with installation_faq.rst is that the section
> titles are not questions, but that is a minor issue here.
>
> Ben Root
>

On Tue, Jun 7, 2011 at 5:01 PM, Eric Firing <ef...@ha...> wrote:

> On 06/07/2011 11:46 AM, Benjamin Root wrote:
> > On Saturday, June 4, 2011, Eric Firing<ef...@ha...>  wrote:
> >>
> >>
> >>
> https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
> >>
> >> Eric, Ben,
> >>
> >> See if the section "What is interactive mode" makes sense to you.  I
> have just added it to a feature branch (which includes some other faq
> madifications, mainly moving the backend section from installation to
> usage), but have not yet generated a pull request.  It doesn't go into every
> detail, or into the underlying machinery.  It is intended to provide just
> enough understanding to clear up user-level confusion about interactive
> mode, show, and draw, and let most relatively new users get on with their
> work.
> >>
> >> Eric
> >>
> >
> > Eric,
> >
> > I see where you are going with this, and this is valuable information
> > to include in the docs. However, the interactive mode and backend info
> > doesn't seem to fit properly with everything else on the page.  I am
>
> I don't see why not.  A FAQ is a place for answers to questions, and
> this is the usage section of the FAQ, so I don't see any inherent reason
> why information about backends and interactive mode, both of which
> involve mpl usage, can't go there.  There may be better places, to which
> the FAQ could refer, but I think the FAQ is better than nothing.  I
> moved the backend piece from the installation part of the FAQ, where it
> *really* didn't belong.  (And the remaining installation part is also an
> out-of-date worm jar.)
>

I am looking at doc/faq/installing_faq.rst on your branch, and I can't tell
what is out-of-date (although the Mac part might be, I don't know).  If you
are referring to doc/users/installing.rst, that should have been removed in
the big set of commits I made recently when I merged from v1.0.x-maint to
master (the INSTALL file is now used in master for the installation docs).

The problem I do see with installation_faq.rst is that the section titles
are not questions, but that is a minor issue here.

Ben Root

On 09.06.2011 19:52:18 Benjamin Root wrote:

> You could also just edit your copy
> of the file C:\Python26\lib\site-
> packages\matplotlib\backends\backend_emf.py so that [:3] is added to the end
> of lines 69 and 105.  This page should show you what changes you need:
> https://github.com/WeatherGod/matplotlib/commit/bf8d9d6f7cea1546c736d3897387698e6ae5e5b3
> 
> I hope that helps!

Thanks. It outputs fine now :)


Cheers

On Thu, Jun 9, 2011 at 12:40 PM, Klonuo Umom <kl...@gm...> wrote:

> On 09.06.2011 19:29:35 Benjamin Root wrote:
>
> > I looks like backend_emf.py is choking on rgba values.  Is EMF unable to
> > handle Alpha channels?  The fix should be fairly easy, though.
> >
>
> I have no idea. I installed pyemf today as mpl asked me to if I want to
> export to EMF.
>
> I wanted to use EMF as it's most convenient to use in Word. Hassle free
> vector format that MS likes. It's not problem for me to convert PS/EPS
> to EMF, thou problem should be known
>
>

I set up pull requests to fix this problem, so the v1.0.x-maint branch and
the master branch should soon have the fixes commited to them.  You can get
the latest bugfixed branch for v1.0.1 at
https://github.com/matplotlib/matplotlib/tree/v1.0.x-maint, although that
would mean having to build from source.  You could also just edit your copy
of the file C:\Python26\lib\site-
packages\matplotlib\backends\backend_emf.py so that [:3] is added to the end
of lines 69 and 105.  This page should show you what changes you need:
https://github.com/WeatherGod/matplotlib/commit/bf8d9d6f7cea1546c736d3897387698e6ae5e5b3

I hope that helps!

Ben Root

Thanks Stan, you're 100% right! Usually I load a set of rcParams with
another font and that's why I don't have that problem:

## PNG output:
pylab.rcParams['text.usetex'] = False
## schöner sans-serif Font *ohne* LaTeX: 'stixsans'
pylab.rcParams['mathtext.fontset'] = 'stixsans'
## LaTeX-PDF output:
pylab.rcParams['text.usetex'] = True
pylab.rcParams['text.latex.unicode'] = True
pylab.rcParams['text.latex.preamble'] = [
    '\usepackage{lmodern}',
    '\usepackage[T1]{fontenc}',
    '\usepackage{sfmath}',
    '\usepackage{gensymb}',
    '\usepackage{amsmath}',
]

Thanks a lot for clarification!

2011/6/9 Stan West <sta...@nr...>:
>> From: Daniel Mader [mailto:dan...@go...]
>> Sent: Thursday, June 09, 2011 11:59
>>
>> Hi,
>>
>> I just noticed this doesn't work here, too, as I expected :(
>>
>> with u'äöüß°€' I can print the string, but the labels are still broken
>> in the plot:
>>
>> # -*- coding: utf-8 -*-
>>
>> import matplotlib.pyplot as plt
>> plt.plot([1,2,3,4])
>>
>> xlabel = r'öäüß°€'
>> plt.xlabel(xlabel)
>> plt.show()
>> plt.savefig('asdf')
>>
>> Would be interesting to know what's going on...
>
> What font was used for the label?
>
>    >>> plt.gca().xaxis.label.get_fontname()
>    'Bitstream Vera Sans'
>
> The usual default above has a limited character set.  You can select a font that has the characters you want using
>
>    plt.xlabel(u'äöüß°€', fontdict={'family': 'Cambria'})
>
> for a given bit of text or
>
>    plt.rc('font', family='Cambria')
>
> to make it the default.
>
>

On 09.06.2011 19:29:35 Benjamin Root wrote:

> I looks like backend_emf.py is choking on rgba values.  Is EMF unable to
> handle Alpha channels?  The fix should be fairly easy, though.
> 

I have no idea. I installed pyemf today as mpl asked me to if I want to
export to EMF.

I wanted to use EMF as it's most convenient to use in Word. Hassle free
vector format that MS likes. It's not problem for me to convert PS/EPS
to EMF, thou problem should be known

> From: Daniel Mader [mailto:dan...@go...] 
> Sent: Thursday, June 09, 2011 11:59
> 
> Hi,
> 
> I just noticed this doesn't work here, too, as I expected :(
> 
> with u'äöüß°€' I can print the string, but the labels are still broken
> in the plot:
> 
> # -*- coding: utf-8 -*-
> 
> import matplotlib.pyplot as plt
> plt.plot([1,2,3,4])
> 
> xlabel = r'öäüß°€'
> plt.xlabel(xlabel)
> plt.show()
> plt.savefig('asdf')
> 
> Would be interesting to know what's going on...

What font was used for the label?

    >>> plt.gca().xaxis.label.get_fontname()
    'Bitstream Vera Sans'

The usual default above has a limited character set.  You can select a font that has the characters you want using

    plt.xlabel(u'äöüß°€', fontdict={'family': 'Cambria'})

for a given bit of text or

    plt.rc('font', family='Cambria')

to make it the default.

On Thu, Jun 9, 2011 at 12:02 PM, Klonuo Umom <kl...@gm...> wrote:

> On 09.06.2011 19:00:34 Benjamin Root wrote:
>
> > Ah, so the bug is in the emf backend.  Which version of matplotlib are
> you
> > using?
> >
> > import matplotlib
> > print matplotlib.__version__
>
>
> Latest stable I guess: 1.0.1
>

I looks like backend_emf.py is choking on rgba values.  Is EMF unable to
handle Alpha channels?  The fix should be fairly easy, though.

Ben Root

On 09.06.2011 19:00:34 Benjamin Root wrote:

> Ah, so the bug is in the emf backend.  Which version of matplotlib are you
> using?
> 
> import matplotlib
> print matplotlib.__version__


Latest stable I guess: 1.0.1

On Thu, Jun 9, 2011 at 11:56 AM, Klonuo Umom <kl...@gm...> wrote:

> On 09.06.2011 18:47:42 Benjamin Root wrote:
>
> > Question, does the following cause the same error?
> >
> > from pylab import *
> > plot([1, 2, 3])
> > savefig('foobar.emf')
> >
> > There might be an important difference between saving from the save
> dialog
> > and saving directly through the savefig command.
> >
>
> Good idea. Here is trace (I called your snippet mpl.py):
>
> Traceback (most recent call last):
>  File "C:\Python26\Scripts\mpl.py", line 3, in <module>
>    savefig('foobar.emf')
>  File "C:\Python26\lib\site-packages\matplotlib\pyplot.py", line 363, in
> savefig
>    return fig.savefig(*args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 1084, in
> savefig
>    self.canvas.print_figure(*args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_wxagg.py",
> line 100, in print_figure
>    FigureCanvasAgg.print_figure(self, filename, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line
> 1923, in print_figure
>    **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line
> 1723, in print_emf
>    return emf.print_emf(*args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py",
> line 717, in print_emf
>    self.figure.draw(renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in
> draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 738, in
> draw
>    if self.frameon: self.patch.draw(renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in
> draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\patches.py", line 411, in
> draw
>    renderer.draw_path(gc, tpath, affine, rgbFace)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py",
> line 258, in draw_path
>    self.select_brush(rgbFace)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py",
> line 565, in select_brush
>    brush=EMFBrush(self.emf,rgb)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py",
> line 105, in __init__
>    r,g,b=rgb
> ValueError: too many values to unpack
>


Ah, so the bug is in the emf backend.  Which version of matplotlib are you
using?

import matplotlib
print matplotlib.__version__


Ben Root

On 09.06.2011 18:47:42 Benjamin Root wrote:

> Question, does the following cause the same error?
> 
> from pylab import *
> plot([1, 2, 3])
> savefig('foobar.emf')
> 
> There might be an important difference between saving from the save dialog
> and saving directly through the savefig command.
> 

Good idea. Here is trace (I called your snippet mpl.py):

Traceback (most recent call last):
  File "C:\Python26\Scripts\mpl.py", line 3, in <module>
    savefig('foobar.emf')
  File "C:\Python26\lib\site-packages\matplotlib\pyplot.py", line 363, in savefig
    return fig.savefig(*args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 1084, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_wxagg.py", line 100, in print_figure
    FigureCanvasAgg.print_figure(self, filename, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line 1923, in print_figure
    **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\backend_bases.py", line 1723, in print_emf
    return emf.print_emf(*args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py", line 717, in print_emf
    self.figure.draw(renderer)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 738, in draw
    if self.frameon: self.patch.draw(renderer)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\patches.py", line 411, in draw
    renderer.draw_path(gc, tpath, affine, rgbFace)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py", line 258, in draw_path
    self.select_brush(rgbFace)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py", line 565, in select_brush
    brush=EMFBrush(self.emf,rgb)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_emf.py", line 105, in __init__
    r,g,b=rgb
ValueError: too many values to unpack

I also use LaTeX with utf8 input encoding (and imho the required
preamble is fully OK since it is 100% LaTeX) when generating PDF
graphics -- but I do that only on a Linux box, so I can't verify for
Windows...

2011/6/9 Klonuo Umom <kl...@gm...>:
> AFAIK I used this when working LaTeX in UTF-8:
> =======================================
> \usepackage[utf8] {inputenc}
> \usepackage [T2A] {fontenc}
> ---------------------------------------

On Thu, Jun 9, 2011 at 11:19 AM, Klonuo Umom <kl...@gm...> wrote:

> On 09.06.2011 18:06:57 Nick Veitch wrote:
>
> > Some code sample would help. It means what it says - trying to assign
> > tuples or whatever to too few values, e.g.:
> > x,y= (1,2,3)
> >
> > Is the error raised in your code or a library?
>
> Take any for example, like 'plot([1,2,3])' it doesn't matter
>
> I described my environment: I use matplotlib through IPython on Windows
> XP with Python 2.6.6 and Qt4Agg as backend
>
> Qt backend shows the plot, then I press save icon and choose EMF. Next,
> Qt pops dialog saying 'too many values to unpack'.
> Same happens also with WXAgg. Seems like it's something broken between
> matplotlib and pyemf, but I don't see how I can trace this
>
> Saving PNG, EPS works fine as expected
>
>
Question, does the following cause the same error?

from pylab import *
plot([1, 2, 3])
savefig('foobar.emf')

There might be an important difference between saving from the save dialog
and saving directly through the savefig command.

Ben Root

On Thu, Jun 9, 2011 at 10:13 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thu, Jun 9, 2011 at 6:25 AM, Richard Hofmeister <
> ric...@io...> wrote:
>
>> Hello mplot3d specialists,
>>
>> I would like to change the aspect ratio of the 3d axes similar to matlab's
>> functionality with daspect() or the 'dataaspectratio' property of 3d-axes.
>> In the end, the x-y-plane should be non-square due to different lengths
>> (not range) of the x and y axis (i know that i can use the aspect property
>> of the axes to set the x-z/y-z aspect ratio).
>>
>> There is also the package "scitools", which provides all the matlab-3d
>> functions including daspect via a VTK-backend; that would be my next try.
>>
>> For the simple 3d-plotting without fancy shading, i would like to stick to
>> mplot3d:
>> Is it possible to change the axis lengths/aspect ratios independently?
>>
>> Richard
>>
>>
> Richard,
>
> Good question.  I have never thought about such a feature for mplot3d.
> Looking back at the code, it does not appear to be feasible to do in its
> current state, as the code seems to assume that the 3d grid is a constructed
> from a unit cube.  However, I will see if I can add aspect multipliers to
> the point calculation and get arbitrary aspects.  Maybe I can get that
> feature added into the upcoming 1.1.0 release.
>
> Ben Root
>
>
Richard,

I took a look at how this might be implemented.  There would have to be some
extra work to make the plots look right when experiencing changes in
aspect.  I first tried an implementation of just the plot box aspect ratio
(pbaspect) as a member variable of the axes object.  It will probably turn
into a property so that I can link it with a daspect value.  Also, the
values should be normalized to 1, unless you want to see some interesting
shrinkage/growth of your plot area.

Try my branch here:
https://github.com/WeatherGod/matplotlib/tree/mplot3d/pbaspect

After building that branch, try the following script (shamelessly adapted
from some Matlab help pages for pbaspect and daspect).

import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D
import numpy as np

fig = plt.figure()
ax = fig.gca(projection='3d')

x, y = np.mgrid[-2:2:.2, -2:2:.2]
z = x * np.exp(-x**2 - y**2)
ax.plot_surface(x, y, z, rstride=1, cstride=1)
ax.pbaspect = [1.0, 1.0, 0.25]
plt.show()

While this will squash the z-axis nicely, it does not force the z-ticks to
be pruned, so it gets a little ugly.  However, the axis ticks can be changed
manually.  Also, with some of my other changes coming soon, it should be
possible for the Axes3D object to automatically adjust the spacing of the
tick labels so that it is not impacted by the changes in aspect ratio in the
perpendicular direction (i.e. - the x and y tick labels are closer to the
axis due to the z-axis scaling).

Keep an eye on that branch as I work to improve this feature, and feel free
to contribute to it as well!

Ben Root

On 09.06.2011 17:58:49 Daniel Mader wrote:

> Hi,
> 
> I just noticed this doesn't work here, too, as I expected :(
> 
> with u'äöüß°€' I can print the string, but the labels are still broken
> in the plot:
> 
> # -*- coding: utf-8 -*-
> 
> import matplotlib.pyplot as plt
> plt.plot([1,2,3,4])
> 
> xlabel = r'öäüß°€'
> plt.xlabel(xlabel)
> plt.show()
> plt.savefig('asdf')
> 
> Would be interesting to know what's going on...


Yeah, that could be nice :)

Out of curiosity I tried to complicate my life and use TeX for 
annotation. It's great feature of course, it shows 'regular' text fine, 
but still can't do UTF-8. 

AFAIK I used this when working LaTeX in UTF-8:
=======================================
\usepackage[utf8] {inputenc}
\usepackage [T2A] {fontenc}
---------------------------------------

but can't now dig inside mpl code for any little detail, then try to
solve yet another...

IMHO this things should be more easier to set. I quickly browsed
matplolibrc, but can't see how I can solve this

On 09.06.2011 18:06:57 Nick Veitch wrote:

> Some code sample would help. It means what it says - trying to assign
> tuples or whatever to too few values, e.g.:
> x,y= (1,2,3)
> 
> Is the error raised in your code or a library?

Take any for example, like 'plot([1,2,3])' it doesn't matter

I described my environment: I use matplotlib through IPython on Windows
XP with Python 2.6.6 and Qt4Agg as backend

Qt backend shows the plot, then I press save icon and choose EMF. Next,
Qt pops dialog saying 'too many values to unpack'.
Same happens also with WXAgg. Seems like it's something broken between 
matplotlib and pyemf, but I don't see how I can trace this

Saving PNG, EPS works fine as expected

On 9 June 2011 15:13, Klonuo Umom <kl...@gm...> wrote:
>
> Trying to save plot as EMF, after installing pyemf 2.0 raises this
> error:
>
> too many values to unpack
>

Some code sample would help. It means what it says - trying to assign
tuples or whatever to too few values, e.g.:
x,y= (1,2,3)

Is the error raised in your code or a library?


---
Nick

Hi,

I just noticed this doesn't work here, too, as I expected :(

with u'äöüß°€' I can print the string, but the labels are still broken
in the plot:

# -*- coding: utf-8 -*-

import matplotlib.pyplot as plt
plt.plot([1,2,3,4])

xlabel = r'öäüß°€'
plt.xlabel(xlabel)
plt.show()
plt.savefig('asdf')

Would be interesting to know what's going on...


2011/6/9 Klonuo Umom <kl...@gm...>:
> Here is trace if I run this UTF-8 encoded file:
>
> =======================================
> #-*- coding: utf-8 -*-
> import matplotlib.pyplot as plt
> plt.plot([1,2,3,4])
> plt.ylabel(r'Пајтон')
> plt.show()
> ---------------------------------------
>
> on command line:
>
> =======================================
> Traceback (most recent call last):
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_qt4.py", line 208, in resizeEvent
>    self.draw()
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_qt4agg.py", line 130, in draw
>    FigureCanvasAgg.draw(self)
>  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_agg.py", line 394, in draw
>    self.figure.draw(self.renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 798, in draw
>    func(*args)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\axes.py", line 1946, in draw
>    a.draw(renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\axis.py", line 1032, in draw
>    self.label.draw(renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
>    draw(artist, renderer, *args, **kwargs)
>  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 526, in draw
>    bbox, info = self._get_layout(renderer)
>  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 305, in _get_layout
>    clean_line, ismath = self.is_math_text(line)
>  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 989, in is_math_text
>    if cbook.is_math_text(s):
>  File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 1793, in is_math_text
>    s = unicode(s)
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Here is trace if I run this UTF-8 encoded file:

=======================================
#-*- coding: utf-8 -*-
import matplotlib.pyplot as plt
plt.plot([1,2,3,4])
plt.ylabel(r'Пајтон')
plt.show()
---------------------------------------

on command line:

=======================================
Traceback (most recent call last):
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_qt4.py", line 208, in resizeEvent
    self.draw()
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_qt4agg.py", line 130, in draw
    FigureCanvasAgg.draw(self)
  File "C:\Python26\lib\site-packages\matplotlib\backends\backend_agg.py", line 394, in draw
    self.figure.draw(self.renderer)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\figure.py", line 798, in draw
    func(*args)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\axes.py", line 1946, in draw
    a.draw(renderer)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\axis.py", line 1032, in draw
    self.label.draw(renderer)
  File "C:\Python26\lib\site-packages\matplotlib\artist.py", line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 526, in draw
    bbox, info = self._get_layout(renderer)
  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 305, in _get_layout
    clean_line, ismath = self.is_math_text(line)
  File "C:\Python26\lib\site-packages\matplotlib\text.py", line 989, in is_math_text
    if cbook.is_math_text(s):
  File "C:\Python26\lib\site-packages\matplotlib\cbook.py", line 1793, in is_math_text
    s = unicode(s)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 0: ordinal not in range(128)

I use IPython (as pylab), and Qt4Agg as mpl backend

I was entering annotations in Qt4 'Figure Options' dialog

However, even if I try:

=======================================
import matplotlib.pyplot as plt
plt.plot([1,2,3,4])
plt.ylabel(r'*some non ASCII chars*’)
plt.show()
---------------------------------------

I don't get anything, no even empty rectangles

If I use:

=======================================
plt.ylabel('ASCII text')
---------------------------------------

then I see y axis annotated with ASCII text



On 09.06.2011 16:49:13 Daniel Mader wrote:

> Hi,
> 
> try putting an r in front of your string:
> e.g. label=r'äöü߀'
> 
> And it might help to tell your editor the used encoding, too, by
> putting this as the first line:
> # -*- coding: utf-8 -*-
> 
> 
> Hope this helps,
> Daniel
> 2011/6/9 Klonuo Umom <kl...@gm...>:
> > Hi,
> >
> > How can I use font in my locale or even better UTF-8 for plot
> > annotations?
> >
> > Right now I can see only empty rectangles instead characters when I try
> > to enter anything other then ASCII
> >
> >
> > Thanks
> >
> >
> > ------------------------------------------------------------------------------
> > EditLive Enterprise is the world's most technically advanced content
> > authoring tool. Experience the power of Track Changes, Inline Image
> > Editing and ensure content is compliant with Accessibility Checking.
> > http://p.sf.net/sfu/ephox-dev2dev
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >

> Trying to save plot as EMF, after installing pyemf 2.0 raises this
> error:
>
> too many values to unpack

Some code sample would help. It means what it says - trying to assign
tuples or whatever to too few values, e.g.:
x,y= (1,2,3)

Is the error raised in your code or a library?


---
Nick

On Thu, Jun 9, 2011 at 6:25 AM, Richard Hofmeister <
ric...@io...> wrote:

> Hello mplot3d specialists,
>
> I would like to change the aspect ratio of the 3d axes similar to matlab's
> functionality with daspect() or the 'dataaspectratio' property of 3d-axes.
> In the end, the x-y-plane should be non-square due to different lengths
> (not range) of the x and y axis (i know that i can use the aspect property
> of the axes to set the x-z/y-z aspect ratio).
>
> There is also the package "scitools", which provides all the matlab-3d
> functions including daspect via a VTK-backend; that would be my next try.
>
> For the simple 3d-plotting without fancy shading, i would like to stick to
> mplot3d:
> Is it possible to change the axis lengths/aspect ratios independently?
>
> Richard
>
>
Richard,

Good question.  I have never thought about such a feature for mplot3d.
Looking back at the code, it does not appear to be feasible to do in its
current state, as the code seems to assume that the 3d grid is a constructed
from a unit cube.  However, I will see if I can add aspect multipliers to
the point calculation and get arbitrary aspects.  Maybe I can get that
feature added into the upcoming 1.1.0 release.

Ben Root

Hi,

try putting an r in front of your string:
e.g. label=r'äöü߀'

And it might help to tell your editor the used encoding, too, by
putting this as the first line:
# -*- coding: utf-8 -*-


Hope this helps,
Daniel
2011/6/9 Klonuo Umom <kl...@gm...>:
> Hi,
>
> How can I use font in my locale or even better UTF-8 for plot
> annotations?
>
> Right now I can see only empty rectangles instead characters when I try
> to enter anything other then ASCII
>
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>