matplotlib-devel Mailing List for matplotlib (Page 11)

On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:
> This is maybe another push in the direction of using fontconfig (which
> claims to support otf fonts already). I'd really prefer to go in that
> direction rather than continue to tack on partial reimplementations of it
> in font_manager.py -- but it does complicate dependencies on non-X11
> platforms).
What are the dependency problems? I thought freetype was the only requirement. 
Incidentally, GIMP uses fontconfig on windows, and they comment at 
http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary to what many 
seem to think, fontconfig is in no way dependent on X11, so it does make some 
sense to use it on Windows."
> There is experimental support for using fontconfig (through the commandline
> interface, not an API wrapper), that may work. Just set the USE_FONTCONFIG
> variable to True in font_manager.py. You will have to copy the MPL fonts
> to a system font directory (such as ~/.fonts) in order for fontconfig to
> find them.
>
> (I can also look into this myself when I return to the office on Monday...)
Same here, I'll have a look on Monday.

On Sunday 04 November 2007 9:04:15 am Michael Droettboom wrote:
> I should also add -- it would be really nice to have STIX fonts working in
> the upcoming stable release if possible. Hopefully tomorrow morning I can
> assess how much work that will be and maybe delay tagging the release
> slightly so this can be worked through. It would be nice to remove the
> Computer Modern fonts (in mathtext only), but they still serve a niche in
> that they match the LaTeX fonts for users who can't/won't use usetex. So
> we're probably stuck with them for the long term even if STIX becomes a
> nicer/cleaner option.
I haven't found sans-serif or monospaced fonts in their distribution. Maybe I 
don't know where to look. I sent an email to the STIX website asking about 
them, but havent heard back from them. I tried opening the fonts in 
fontforge, and there are a lot of missing glyphs.
This is a beta release for the STIX fonts, and given how long it took to 
release and the number of self imposed deadlines that came and went, I 
wouldnt be surprised if there were some major issues that will need to be 
worked out. There is supposed to be a package for using STIX with latex, 
which they claim will be out by the end of the year, as will the final font 
release. Maybe we should start a pool!

I should also add -- it would be really nice to have STIX fonts working in the upcoming stable release if possible. Hopefully tomorrow morning I can assess how much work that will be and maybe delay tagging the release slightly so this can be worked through. It would be nice to remove the Computer Modern fonts (in mathtext only), but they still serve a niche in that they match the LaTeX fonts for users who can't/won't use usetex. So we're probably stuck with them for the long term even if STIX becomes a nicer/cleaner option.
Cheers,
Mike

This is maybe another push in the direction of using fontconfig (which claims to support otf fonts already). I'd really prefer to go in that direction rather than continue to tack on partial reimplementations of it in font_manager.py -- but it does complicate dependencies on non-X11 platforms).
There is experimental support for using fontconfig (through the commandline interface, not an API wrapper), that may work. Just set the USE_FONTCONFIG variable to True in font_manager.py. You will have to copy the MPL fonts to a system font directory (such as ~/.fonts) in order for fontconfig to find them.
(I can also look into this myself when I return to the office on Monday...)
Cheers,
Mike

On 11/4/07, Robert Kern <rob...@gm...> wrote:
> Are you using the gfortran from hpc.sf.net? I don't recommend it anymore. I use
> the binary from http://r.research.att.com/tools/. It is universal. That should help.
Yep, I was. That was the binary recommended first on the wiki (at
with a note at the end that some have had problems with it that do not
appear related to my problem). Using the universal binary at the att
site fixed my problem, and I updated the wiki at
http://www.scipy.org/Installing_SciPy/Mac_OS_X.
Now for my next problem: I built zlib, libpng an freetype from source
and I get a
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libpng.dylib,
file is not of required architecture
error when building mpl. Is there an easy way in the
configure/make/make install cycle to tell the compiler to build
universal binaries?
Alternatively, can I instruct distutils to simply not provide the
-arch ppc build? I can see how
this will be a problem down the road, since any non universal library
I install on my system will potentially break my builds.
Thanks,
JDH

John Hunter wrote:
> On 11/4/07, Jouni K Seppänen <jk...@ik...> wrote:
> 
>> Just a guess: Apple's Python is configured to compile everything as universal,
>> but you have installed a non-universal gcc in /usr/local, perhaps as a result
>> of installing some version of gfortran.
> 
> Possibly, but 'which gcc' points to the /usr/bin apple version, and
> the gfortran I installed was fortran only (not the whole gcc suite)
> and is in /usr/local/
> 
> Macintosh:~ jdhunter$ which gcc
> /usr/bin/gcc
> Macintosh:~ jdhunter$ ls -ld /usr/bin/gcc
> lrwxr-xr-x 1 root wheel 7 Nov 3 18:00 /usr/bin/gcc -> gcc-4.0
> Macintosh:~ jdhunter$ ls -ld /usr/bin/gcc-4.0
> -rwxr-xr-x 1 root wheel 93072 Sep 23 17:37 /usr/bin/gcc-4.0
> Macintosh:~ jdhunter$ ls -ld /usr/local/bin/g*
> -rwxr-xr-x 1 root wheel 160 Mar 22 2007 /usr/local/bin/genaxmodule
> -rwxr-xr-x@ 1 root wheel 318168 Oct 31 08:27 /usr/local/bin/gfortran
> 
> mpl should not be invoking gfortran, so I am not sure where the
> problem is creeping in.
Are you using the gfortran from hpc.sf.net? I don't recommend it anymore. I use
the binary from http://r.research.att.com/tools/. It is universal. That should help.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

John Hunter <jdh2358@...> writes:
> > Just a guess: Apple's Python is configured to compile everything as 
> > universal, but you have installed a non-universal gcc in /usr/local, 
> > perhaps as a result of installing some version of gfortran.
> 
> Possibly, but 'which gcc' points to the /usr/bin apple version, and
> the gfortran I installed was fortran only (not the whole gcc suite)
> and is in /usr/local/
You have -L/usr/local/lib in the compile flags, and ld is finding a
libgcc_s.10.4.dylib in /usr/local:
> ld: warning in
> /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.4.dylib,
> missing required architecture ppc in file
-- 
Jouni

On 11/4/07, Jouni K Sepp=E4nen <jk...@ik...> wrote:
> Just a guess: Apple's Python is configured to compile everything as unive=
rsal,
> but you have installed a non-universal gcc in /usr/local, perhaps as a r=
esult
> of installing some version of gfortran.
Possibly, but 'which gcc' points to the /usr/bin apple version, and
the gfortran I installed was fortran only (not the whole gcc suite)
and is in /usr/local/
Macintosh:~ jdhunter$ which gcc
/usr/bin/gcc
Macintosh:~ jdhunter$ ls -ld /usr/bin/gcc
lrwxr-xr-x 1 root wheel 7 Nov 3 18:00 /usr/bin/gcc -> gcc-4.0
Macintosh:~ jdhunter$ ls -ld /usr/bin/gcc-4.0
-rwxr-xr-x 1 root wheel 93072 Sep 23 17:37 /usr/bin/gcc-4.0
Macintosh:~ jdhunter$ ls -ld /usr/local/bin/g*
-rwxr-xr-x 1 root wheel 160 Mar 22 2007 /usr/local/bin/genaxmodule
-rwxr-xr-x@ 1 root wheel 318168 Oct 31 08:27 /usr/local/bin/gfortran
mpl should not be invoking gfortran, so I am not sure where the
problem is creeping in.
JDH
JDH

John Hunter <jdh2358@...> writes:
> ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib,
> missing required architecture ppc in file for architecture ppc
> collect2: ld returned 1 exit status
Just a guess: Apple's Python is configured to compile everything as universal,
but you have installed a non-universal gcc in /usr/local, perhaps as a result
of installing some version of gfortran.
-- 
Jouni

I have a new intel powerbook running OS X 10.5
(leopard) which I upgraded via DVD from a factory installed 10.4. I
decided to take detailed notes on every step of configuring the box as
a development machine for scientific python, figuring it would be
useful to others. The install of ipython, numpy and scipy went really
well (only one snag in scipy following the wiki, which I updated and
is noted in my notes below). But the main problem, sadly, is a
strange problem I've hit trying to compile matplotlib.
My compile is dying with a mysterious
warning about PPC (how did that get in to the compiler flags?) with
some strange hybrid
of 10.4 and 10.3 stuff in the gcc command. If I manually paste in the
g++ command below and remove the -arch ppc part, it compiles fine, so
this is the source of my problems. I don't know if this is a feature
or a bug (universal binary support?) but if someone could advise me
what or where is going wrong and how to fix it, that would be great.
Here is the shorted build output with the compiler command and error:
BUILDING MATPLOTLIB
 matplotlib: 0.90.1
 python: 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1
 (Apple Computer, Inc. build 5341)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.0.4.dev4380
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL DEPENDENCIES
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.3.0
 * WxAgg extension not required for wxPython >= 2.8
 Qt: no
 Qt4: no
 Cairo: no
 libpng: found, but unknown version (no pkg-config)
[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
creating build
creating build/lib.macosx-10.3-fat-2.5
copying lib/pylab.py -> build/lib.macosx-10.3-fat-2.5
creating build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/__init__.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/_cm.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/_mathtext_data.py ->
build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/_pylab_helpers.py ->
build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/afm.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/agg.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/art3d.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
copying lib/matplotlib/artist.py -> build/lib.macosx-10.3-fat-2.5/matplotlib
..snip lots of copying....
running build_ext
building 'matplotlib.ft2font' extension
C compiler: gcc -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double
-no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3
creating build/temp.macosx-10.3-fat-2.5
creating build/temp.macosx-10.3-fat-2.5/src
creating build/temp.macosx-10.3-fat-2.5/CXX
compile options: '-I/usr/local/include -I/usr/include -I.
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5
-c'
gcc: CXX/cxxextensions.c
In file included from /usr/include/math.h:26,
 from
/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/pyport.h:200,
 from
/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/Python.h:57,
 from ./CXX/WrapPython.h:47,
 from CXX/cxxextensions.c:38:
/usr/include/architecture/ppc/math.h:675: warning: conflicting types
for built-in function 'scalb'
gcc: CXX/cxx_extensions.cxx
gcc: src/ft2font.cpp
gcc: CXX/IndirectPythonInterface.cxx
gcc: src/mplutils.cpp
gcc: CXX/cxxsupport.cxx
g++ -arch i386 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g
-bundle -undefined dynamic_lookup
build/temp.macosx-10.3-fat-2.5/src/ft2font.o
build/temp.macosx-10.3-fat-2.5/src/mplutils.o
build/temp.macosx-10.3-fat-2.5/CXX/cxx_extensions.o
build/temp.macosx-10.3-fat-2.5/CXX/cxxsupport.o
build/temp.macosx-10.3-fat-2.5/CXX/IndirectPythonInterface.o
build/temp.macosx-10.3-fat-2.5/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -lfreetype -lz -lstdc++ -lm -o
build/lib.macosx-10.3-fat-2.5/matplotlib/ft2font.so
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libfreetype.dylib,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.4.dylib,
missing required architecture ppc in file
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib,
missing required architecture ppc in file for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/qT/qTRms9cJHNqoYnbs9+TwVk+++TI/-Tmp-//ccMsnFzZ.out (No
such file or directory)
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libfreetype.dylib,
file is not of required architecture
ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.10.4.dylib,
missing required architecture ppc in file
ld: in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/libgcc_s.1.dylib,
missing required architecture ppc in file for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file:
/var/folders/qT/qTRms9cJHNqoYnbs9+TwVk+++TI/-Tmp-//ccMsnFzZ.out (No
such file or directory)
error: Command "g++ -arch i386 -arch ppc -isysroot
/Developer/SDKs/MacOSX10.4u.sdk -g -bundle -undefined dynamic_lookup
build/temp.macosx-10.3-fat-2.5/src/ft2font.o
build/temp.macosx-10.3-fat-2.5/src/mplutils.o
build/temp.macosx-10.3-fat-2.5/CXX/cxx_extensions.o
build/temp.macosx-10.3-fat-2.5/CXX/cxxsupport.o
build/temp.macosx-10.3-fat-2.5/CXX/IndirectPythonInterface.o
build/temp.macosx-10.3-fat-2.5/CXX/cxxextensions.o -L/usr/local/lib
-L/usr/lib -lfreetype -lz -lstdc++ -lm -o
build/lib.macosx-10.3-fat-2.5/matplotlib/ft2font.so" failed with exit
status 1
Macintosh:matplotlib jdhunter$

This is much worse than I thought. The "inch" unit is used in many places in
matplotlib. In particular in `figure` and `savefig`. Please, please consider
allowing other units. Let me emphasise this once more: in Europe, and, I
believe in most places around the world, one NEVER uses inches. Neither in
engineering nor, i think, in typography. For most people "inch" is basically
an unusual measure of how big screens are. I'm not kidding. Same for dpi,
it's a specific measurement of a resolution but nobody thinks of it as a
number of pixels per inches.
I have nothing against an internal use of inches inside matplotlib but
please consider allowing other units for all kinds of interfaces with the
user!
The best choice in my opinion would be to have a unit preference in the
.matplotlibrc file. This unit could be, say, `inch` or `cm` (or mm). Then
any length would be expressed using this unit of length. That seems simple
enough, doesn't it?
How difficult would it be to implement this?
As I said before, I'm willing to help for this.
cheers,
== Olivier
On 29/10/2007, Christopher Barker <Chr...@no...> wrote:
>
> Eric Firing wrote:
> > Somewhere along the line, it may make sense to support the metric system
> > better in mpl.
>
> It seems to me that the "right" way to do this is to use some sort of
> "array-with_units" class. Then what MPL would except was a "length", and
> the user would specify what they want. i.e:
>
> figure(figsize = units.inches((8.5,11))
>
> rather than:
>
> figure(figsize = (8.5, 11), units=inches)
>
> Though this does make for more typing. With the later way, a system
> default for units could be used more easily.
>
> I really want a unit class like this for other stuff anyway.
>
> -- just thinking in email....
>
> -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...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thursday 27 September 2007 05:54:45 pm Stefan van der Walt wrote:
> Hi all,
>
> When trying to print a matplotlib-generated .eps file with CUPS, it
> aborts, complaining
>
> No %%Pages: comment in header!
>
> An easy workaround is to do
>
> eps2eps broken.eps fixed.eps
>
> but maybe the %%Pages directive should be included in the output?
According to the EPS specification 
(http://partners.adobe.com/public/developer/en/ps/5002.EPSF_Spec.pdf), the 
only required comments in the header are:
%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox: llx lly urx ury
I have never seen an error from CUPS due to a missing PAGES comment, what 
version of cups are you using?
Darren

On 11/2/07, Eric Firing <ef...@ha...> wrote:
> Now I am not so sure that the use of lists in errorbar is a fossil, but
> I certainly don't understand it. Would you give a summary of when one
> can and cannot use arrays in axes.py, please? The errorbar and bar
> methods seem to be the only victims of this restriction, and it looks
> like some of the instances are accomplishing nothing--the arguments get
> converted to arrays with the next method call anyway. I haven't tried
> to trace things carefully, obviously.
I just wrote some related stuff in the other thread, but will jump in
here. I think I may be being overzealous in my avoidance of arrays. What
we cannot assume is that asarray is creating an array of floats, so we
cannot do scalar array operations, eg 2*x. But we should be able to
assume object arrays, with indexing, and element wise opertations
which are well defined, eg for the canonical date example.
In [3]: import datetime
In [4]: date0 = datetime.date(2004,1,1)
In [5]: days = datetime.timedelta(days=1)
In [6]: d = [date0, date0+days, date0+2*days, date0+3*days]
In [7]: import numpy as n
In [8]: x1 = n.array(d)
In [9]: xerr = n.array([days]*len(x1))
In [10]: x1.dtype
Out[10]: dtype('object')
In [11]: x2.dtype
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
NameError: name 'x2' is not defined
In [12]: xerr.dtype
Out[12]: dtype('object')
In [13]: x1 + xerr
Out[13]: array([2004年01月02日, 2004年01月03日, 2004年01月04日, 2004年01月05日], dtype=object)
The reason we are bumping into so may problems with errorbar is not
only because it is complex, but because it is doing more arithmetic
than other plotting code.
Ted, can you clarify what kinds of operations are permitted with your
iterable unit objects if they are initialized into numpy object
arrays?

On 11/2/07, Eric Firing <ef...@ha...> wrote:
> It looks to me like there are several fossils from John's early work
> with units support--places where list comprehensions are used instead of
> arrays "to preserve units". I don't think these are directly causing
> the problem, but if they are indeed fossils they should certainly be
> corrected.
I just fixed this in svn -- the unit support has certainly proven
fragile in the errorbar code, because the inability to assume arrays
is a major handicap, and barring oneself from all the numpyisms like
logical masks and fancy indexing, not to mention the performance that
comes with it, is frustrating.
The unit support code grew out of an attempt to solve a somewhat
important use case: the JPL has unit enabled data structures that are
iterable but do not implement the basic array uses we need.
Apparently, they use these objects with mpl and are unable to wrap
them or modify them because they must also be passed on to other
libraries in their system, which they also do not control, unmodified.
 The current mpl implementation, in which users can register their
objects with converter classes, works fine and supports the very nice
ability to pass in datetime objects directly to mpl (this is another
clear use case where you want to work with some object you can't wrap
or modify).
I think it is a bit too onerous inside mpl to not be able to assume we
can do array operations, so I will give this some more thought on how
we can satisfy these use cases w/o writing tedious, fragile code.
JDH

John,
Now I am not so sure that the use of lists in errorbar is a fossil, but 
I certainly don't understand it. Would you give a summary of when one 
can and cannot use arrays in axes.py, please? The errorbar and bar 
methods seem to be the only victims of this restriction, and it looks 
like some of the instances are accomplishing nothing--the arguments get 
converted to arrays with the next method call anyway. I haven't tried 
to trace things carefully, obviously.
Eric

Darren Dale wrote:
> The errorbar_limits.py demo is failing on my machine:
> 
> Traceback (most recent call last):
> File "errorbar_limits.py", line 13, in <module>
> P.errorbar(x,y,yerr=0.1,capsize=3)
> File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, 
> in errorbar
> ret = gca().errorbar(*args, **kwargs)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in 
> errorbar
> caplines.extend( self.plot(x, lower, 'k_', **plot_kw) )
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in 
> plot
> for line in self._get_lines(*args, **kwargs):
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in 
> _grab_next_args
> for seg in self._plot_3_args(remaining, **kwargs):
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in 
> _plot_3_args
> x, y, multicol = self._xy_from_xy(x, y)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in 
> _xy_from_xy
> assert nrx == nry, 'Dimensions of x and y are incompatible'
> AssertionError: Dimensions of x and y are incompatible
> 
> 
> It looks like the API has changed and does not allow scalar arguments for the 
> errors. I tried setting yerr=ones(len(y))*0.1, and got a different error: 
> 
> Traceback (most recent call last):
> File "errorbar_limits.py", line 18, in <module>
> P.errorbar(x,y,yerr=yerr, uplims=True)
> File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, 
> in errorbar
> ret = gca().errorbar(*args, **kwargs)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in 
> errorbar
> caplines.extend( self.plot(x[uplims], upper[uplims], ls='None', 
> marker=mlines.CARETUP, **plot_kw) )
> TypeError: only integer arrays with one element can be converted to an index
> 
> 
> Maybe the patch commited on September 3 needs to be revisited.
I'm not sure that the problem is just in that patch, or in that patch at 
all--the whole errorbar method needs to be reviewed. (The patch 
contributes to the extent that it makes the code much more complicated.)
It looks to me like there are several fossils from John's early work 
with units support--places where list comprehensions are used instead of 
arrays "to preserve units". I don't think these are directly causing 
the problem, but if they are indeed fossils they should certainly be 
corrected.
Eric
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Bug 1750527 reports that, with usetex, it is not possible to rotate text or 
ticklabels by 45 degrees. It looks like this limitation is caused by 
_backend_agg's draw_image method, which does not accept an angle argument, 
while draw_text_image does. I am out of my depth in _backend_agg.cpp, can 
draw_image be updated to accept an angle?
Darren

The errorbar_limits.py demo is failing on my machine:
Traceback (most recent call last):
 File "errorbar_limits.py", line 13, in <module>
 P.errorbar(x,y,yerr=0.1,capsize=3)
 File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, 
in errorbar
 ret = gca().errorbar(*args, **kwargs)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3735, in 
errorbar
 caplines.extend( self.plot(x, lower, 'k_', **plot_kw) )
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2634, in 
plot
 for line in self._get_lines(*args, **kwargs):
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 403, in 
_grab_next_args
 for seg in self._plot_3_args(remaining, **kwargs):
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 349, in 
_plot_3_args
 x, y, multicol = self._xy_from_xy(x, y)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 244, in 
_xy_from_xy
 assert nrx == nry, 'Dimensions of x and y are incompatible'
AssertionError: Dimensions of x and y are incompatible
It looks like the API has changed and does not allow scalar arguments for the 
errors. I tried setting yerr=ones(len(y))*0.1, and got a different error: 
Traceback (most recent call last):
 File "errorbar_limits.py", line 18, in <module>
 P.errorbar(x,y,yerr=yerr, uplims=True)
 File "/usr/lib64/python2.5/site-packages/matplotlib/pyplot.py", line 1608, 
in errorbar
 ret = gca().errorbar(*args, **kwargs)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 3738, in 
errorbar
 caplines.extend( self.plot(x[uplims], upper[uplims], ls='None', 
marker=mlines.CARETUP, **plot_kw) )
TypeError: only integer arrays with one element can be converted to an index
Maybe the patch commited on September 3 needs to be revisited.
Darren

On 11/2/07, Manuel Metz <mm...@as...> wrote:
> Hi,
> attached is a patch for contour.py against latest svn that adds support
> for the keyword "linestyles" for contour plots. Could someone commit
> that to svn?
Thanks Manuel -- I applied this to svn.
JDH

Thanks. I updated the gs version checker in svn.
On Thursday 01 November 2007 05:29:03 pm Gary Ruben wrote:
> Yep. Works.
>
> C:\WINDOWS>gswin32c --version
> 8.51
>
> Darren Dale wrote:
> > gs --version works with AFPL. Could someone please check that this works
> > on windows: gswin32c --version
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
attached is a patch for contour.py against latest svn that adds support 
for the keyword "linestyles" for contour plots. Could someone commit 
that to svn?
Manuel

Yep. Works.
C:\WINDOWS>gswin32c --version
8.51
Darren Dale wrote:
> gs --version works with AFPL. Could someone please check that this works on 
> windows: gswin32c --version
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Wednesday 31 October 2007 10:03:39 am Darren Dale wrote:
> On Tuesday 30 October 2007 09:33:53 pm Ralf Gommers wrote:
> > Hi all,
> >
> > I just installed mpl on ubuntu gutsy, and got errors after setting
> > text.usetex : True and ps.usedistiller : ghostscript. The problem
> > seems to be in checkdep_ghostscript() in __init__.py, specifically the
> > command 'gs -v' (should be replaced by 'gs --version').
> > For my system I get:
> > $ gs -v
> > GPL Ghostscript SVN PRE-RELEASE 8.61 (2007年08月02日)
> > Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
> >
> > and:
> > $ gs --version
> > 8.61
> >
> > Below I give a modified version of checkdep_ghostscript() that should
> > work for all version of ghostscript.
> >
> > Cheers,
> > Ralf
> >
> >
> >
> > def checkdep_ghostscript():
> > try:
> > if sys.platform == 'win32':
> > command = 'gswin32c -v'
> > else:
> > command = 'gs --version'
> > stdin, stdout = os.popen4(command)
> > line = stdout.readlines()[0]
> > vtest = '.'.join(line.split('.')[:2]) # deal with version numbers
> > like ' 7.07.1'
> > float(vtest)
> > return vtest
> > except (IndexError, ValueError):
> > return None
>
> Thanks for the report. This was already fixed in svn, but not using
> --version, which looks like a better solution. Could someone using AFPL
> ghostscript let us know what is the output of gs --version?
gs --version works with AFPL. Could someone please check that this works on 
windows: gswin32c --version

On Thursday 01 November 2007 08:16:01 am Michael Droettboom wrote:
> That's great news. I'm very curious how they look with mathtext.
>
> I'll be away from the office for the rest of the week. If any of you want
> to try it in the meantime, it's theoretically possible it already works
> (assuming there's no strange metrics issues in the font.) ---> Set
> mathtext.use_cm to False, and then set mathtext.it, .rm etc. to use the
> STIX fonts.
It looks like findfont is not designed to identify OpenType fonts. The STIX 
license allows fonts to be converted, so I could probably generate ttf's, but 
maybe it would be better to modify font_manager to support otfs?
Darren

That's great news. I'm very curious how they look with mathtext.
I'll be away from the office for the rest of the week. If any of you want to try it in the meantime, it's theoretically possible it already works (assuming there's no strange metrics issues in the font.) ---> Set mathtext.use_cm to False, and then set mathtext.it, .rm etc. to use the STIX fonts.
Cheers,
Mike