matplotlib-users Mailing List for matplotlib

Cheng-Kong Wu wrote:
> Dear all,
> 
> I have the following data:
> X = [0.0, 1.0, 3.0, 6.0, 10.0, 15.0]
> Y = [0.0, 1.0, 2.0, 3.0, 4.0, 5.0]
> 
> I can plot the X-Y curve without problem.
> 
> But is there a way for me to make the xticks spaced
> evenly? That is, the distance between 0.0 and 1.0, 1.0
> and 3.0, 3.0 and 6.0, ... along the x-axis are the
> same.

What you are really doing, then, is plotting Y not against X but against 
an index, like this:

from pylab import *
X = [0.0, 1.0, 3.0, 6.0, 10.0, 15.0]
Y = [0.0, 1.0, 2.0, 3.0, 4.0, 5.0]
xi = arange(len(X))
xtlabel = ['%.1d'%x for x in X] # or [str(x) for x in X]
plot(xi, Y)
ax = gca()
ax.set_xticks(xi)
ax.set_xticklabels(xtlabel)
show()

Is this what you want?

Eric

Dear all,

I have the following data:
X = [0.0, 1.0, 3.0, 6.0, 10.0, 15.0]
Y = [0.0, 1.0, 2.0, 3.0, 4.0, 5.0]

I can plot the X-Y curve without problem.

But is there a way for me to make the xticks spaced
evenly? That is, the distance between 0.0 and 1.0, 1.0
and 3.0, 3.0 and 6.0, ... along the x-axis are the
same.

I tried LinearLocator, IndexLocator, but did not work.

Please help! Thanks!
Cheng-Kong


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

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.

http://www.laminarchaos.net/research/slicer_test.tar.gz

I'm now including a link to 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

> 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
>

Also, if you're adventurous, try installing valgrind and running:

valgrind --tool=massif python slicer.py

valgrind --tool=memcheck --leak-check=yes --log-file=slicer_leak python 
slicer.py

and send me the output -- (probably off list because they will be large 
files).

Cheers,
Mike

Aaron Botnick wrote:
> Hi all,
> 
> I'm using MPL to plot a 6 panel figure of 2d data using pcolormesh.  I 
> started this script last night, and found it consuming over 3GB of 
> memory when I got in this morning.  After reading through old posts to 
> this list, I came across this suggestion:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=47558A63.8050307%40cornell.edu&forum_name=matplotlib-users 
> <http://sourceforge.net/mailarchive/forum.php?thread_name=47558A63.8050307%40cornell.edu&forum_name=matplotlib-users>
> 
> ...to use gc.collect(), unfortunately this does not solve my 
> problem...after implementing it, my script is now at nearly 800MB within 
> 15 minutes of running.  I am looping this over several thousand data files.
> 
> I am using MPL - 0.92.2, numpy - 1.0.1, and the Agg backend, and running 
> in non-interactive mode on a Fedora Linux box with Python 2.4.  MPL and 
> numpy were installed from source rather than the distribution.
> 
> Following the suggestion to track down memory-leaks, the 
> cbook.print_cycles(gc.garbage) call returns None at every iteration of 
> the loop.  However, using the comparison of original objects ( 
> gc.get_objects() ) to new objects created after the first loop 
> iteration, there are a lot of new objects present.
> 
> I've included a copy of the script in an attachment (slicer.py).
> 
> Any help would be great, thanks!
> 
> -- Aaron Botnick
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Aaron Botnick wrote:
> I'm using MPL to plot a 6 panel figure of 2d data using pcolormesh.  I 
> started this script last night, and found it consuming over 3GB of 
> memory when I got in this morning.

Another one... ;)

> After reading through old posts to 
> this list, I came across this suggestion:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=47558A63.8050307%40cornell.edu&forum_name=matplotlib-users 
> 
> ...to use gc.collect(), unfortunately this does not solve my 
> problem...after implementing it, my script is now at nearly 800MB within 
> 15 minutes of running.  I am looping this over several thousand data files.
> 
> I am using MPL - 0.92.2,

I assume you mean 0.91.2?

> numpy - 1.0.1, and the Agg backend, and running 
> in non-interactive mode on a Fedora Linux box with Python 2.4.  MPL and 
> numpy were installed from source rather than the distribution.
> 
> Following the suggestion to track down memory-leaks, the 
> cbook.print_cycles(gc.garbage) call returns None at every iteration of 
> the loop.

That function doesn't return anything -- it prints to the console.  Is 
it producing any console output?

>  However, using the comparison of original objects ( 
> gc.get_objects() ) to new objects created after the first loop 
> iteration, there are a lot of new objects present.

Do you know what type those objects are?

> I've included a copy of the script in an attachment (slicer.py).

Would it be possible to get a revised version of the script that doesn't 
require the data files, i.e. just random data that closely resembles 
what's in the files, and reduced to the bare minimum that reproduces the 
leak?  I could hack at it myself for a while, but if I can't reproduce 
the leak, I wouldn't know if it's because I removed something critical 
or the leak is somehow platform-dependent.

Cheers,
Mike

> Any help would be great, thanks!
> 
> -- Aaron Botnick
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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 Thu, 31 Jan 2008, John Prince apparently wrote:

> I think there is a way to set arbitrary 
> dash-dot lines 

Use numbers:
http://matplotlib.sourceforge.net/matplotlib.lines.html

set_dashes(self, seq)
    Set the dash sequence, sequence of dashes with on off ink in
    points.  If seq is empty or if seq = (None, None), the
    linestyle will be set to solid.
     
    ACCEPTS: sequence of on/off ink in points

Note: 1pt = 1/72 inch

hth,
Alan Isaac

> I found this in the online documentation of the pylab.plot() function:
>
> The following line styles are supported:
>
>     -     : solid line
>     --    : dashed line
>     -.    : dash-dot line
>     :     : dotted line
>     .     : points
>     ,     : pixels
>     o     : circle symbols
>     ^     : triangle up symbols
>     v     : triangle down symbols
>     <     : triangle left symbols
>     >     : triangle right symbols
>     s     : square symbols
>     +     : plus symbols
>     x     : cross symbols
>     D     : diamond symbols
>     d     : thin diamond symbols
>     1     : tripod down symbols
>     2     : tripod up symbols
>     3     : tripod left symbols
>     4     : tripod right symbols
>     h     : hexagon symbols
>     H     : rotated hexagon symbols
>     p     : pentagon symbols
>     |     : vertical line symbols
>     _     : horizontal line symbols
>     steps : use gnuplot style 'steps' # kwarg only
>
> The following color abbreviations are supported
>
>     b  : blue
>     g  : green
>     r  : red
>     c  : cyan
>     m  : magenta
>     y  : yellow
>     k  : black
>     w  : white
>
> In addition, you can specify colors in many weird and
> wonderful ways, including full names 'green', hex strings
> '#008000', RGB or RGBA tuples (0,1,0,1) or grayscale
> intensities as a string '0.8'.  Of these, the string
> specifications can be used in place of a fmt group, but the
> tuple forms can be used only as kwargs.
>
> Line styles and colors are combined in a single format string, as in
> 'bo' for blue circles.
>
> The **kwargs can be used to set line properties (any property that has
> a set_* method).  You can use this to set a line label (for auto
> legends), linewidth, anitialising, marker face color, etc.  Here is an
> example:
>
>     plot <http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-plot>
> ([1,2,3], [1,2,3], 'go-', label='line 1', linewidth=2)
>     plot <http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-plot>
> ([1,2,3], [1,4,9], 'rs',  label='line 2')
>     axis <http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-axis>
> ([0, 4, 0, 10])
>     legend<http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-legend>
> ()
>
> HTH,
> -- jv
>

Thanks for the reply.  Those are the formatting codes one can use by
default.  However, there are only 4 dash types accessible from these codes:
solid, dashed, dash-dot, dotted.  I think there is a way to set arbitrary
dash-dot lines (say, '-..-....-') using the 'setp' command with the 'dashes'
argument.  I just don't know what acceptable parameters for that argument
are.  I'm hoping someone knows.

Thanks,
John

John Prince wrote:
> First off, thanks for matplotlib.  It really is amazing.
>
> I can't seem to figure out an acceptable sequence of dashes per the 
> documentation:
> 'dashes: sequence of on/off ink in points'
>
> This is what I'm trying:
>
>
> mydashes = ['- ', '--', '- ', '--', '- ']
>
> lines = plot(*triplets)
>
> for i in range(len(lines)):
>     setp(lines[i], dashes=mydashes[i])
>
>
> I'm getting errors like:
>
> ValueError: invalid literal for float(): -
>
> or a message about even numbers in the dash sequence being required 
> when I don't use even-length strings.
>
> I really need about 5-10 different dash sequences to lines in a 
> publication and the defaults are not quite enough.

Hello John,

I found this in the online documentation of the pylab.plot() function:

The following line styles are supported:
 
    -     : solid line
    --    : dashed line
    -.    : dash-dot line
    :     : dotted line
    .     : points
    ,     : pixels
    o     : circle symbols
    ^     : triangle up symbols
    v     : triangle down symbols
    <     : triangle left symbols
    >     : triangle right symbols
    s     : square symbols
    +     : plus symbols
    x     : cross symbols
    D     : diamond symbols
    d     : thin diamond symbols
    1     : tripod down symbols
    2     : tripod up symbols
    3     : tripod left symbols
    4     : tripod right symbols
    h     : hexagon symbols
    H     : rotated hexagon symbols
    p     : pentagon symbols
    |     : vertical line symbols
    _     : horizontal line symbols
    steps : use gnuplot style 'steps' # kwarg only
 
The following color abbreviations are supported
 
    b  : blue
    g  : green
    r  : red
    c  : cyan
    m  : magenta
    y  : yellow
    k  : black
    w  : white
 
In addition, you can specify colors in many weird and
wonderful ways, including full names 'green', hex strings
'#008000', RGB or RGBA tuples (0,1,0,1) or grayscale
intensities as a string '0.8'.  Of these, the string
specifications can be used in place of a fmt group, but the
tuple forms can be used only as kwargs.
 
Line styles and colors are combined in a single format string, as in
'bo' for blue circles.
 
The **kwargs can be used to set line properties (any property that has
a set_* method).  You can use this to set a line label (for auto
legends), linewidth, anitialising, marker face color, etc.  Here is an
example:
 
    plot 
<http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-plot>([1,2,3], [1,2,3], 'go-', label='line 1', linewidth=2)
    plot 
<http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-plot>([1,2,3], [1,4,9], 'rs',  label='line 2')
    axis 
<http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-axis>([0, 4, 0, 10])
    legend 
<http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-legend>()

HTH,
-- jv

>
> Thanks,
> John
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

On 01/31/2008 02:58 PM, Michael Droettboom wrote:

> More information: this problem reared its ugly head way back in 2005
> and the same font (orlando.ttf) was the culprit then! ;)
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=42E69B61.4060008%40caltech.edu
> 
> Also, is it possible you have PyCXX installed in a system-wide
> location, such as /usr/include/CXX or /usr/include/python2.5/CXX ?  If
> so, the compiler might be included those headers, but building with
> the matplotlib-included ones, causing all kinds of craziness.  Try
> uninstalling pycxx and rebuilding matplotlib and see if that solves
> things.


Thanks for the prompt answer. This was indeed a font-related issue. I
temporarily moved my font collection out of the way -- it is not very
big, but contains some ttf fonts from random web sources -- and then
everything worked. I'll try to find out what font might be the cause,
and isolate it.

And for the record:

$ freetype-config --version
9.16.3

Thanks a lot!

Tiago

-- 
Tiago de Paula Peixoto <ti...@fo...>

First off, thanks for matplotlib.  It really is amazing.

I can't seem to figure out an acceptable sequence of dashes per the
documentation:
'dashes: sequence of on/off ink in points'

This is what I'm trying:


mydashes = ['- ', '--', '- ', '--', '- ']

lines = plot(*triplets)

for i in range(len(lines)):
    setp(lines[i], dashes=mydashes[i])


I'm getting errors like:

ValueError: invalid literal for float(): -

or a message about even numbers in the dash sequence being required when I
don't use even-length strings.

I really need about 5-10 different dash sequences to lines in a publication
and the defaults are not quite enough.

Thanks,
John

Bernhard Voigt wrote:
> Hi Michael,
> 
> attatched is my matplotlibrc file.
> 
> The plot was from some data, but i principle it was crated like that:
> import pylab as p
> import numpy as n
> 
> p.hist(-1 * n.log10(n.random.uniform(size=10000)), 40)
> p.xlabel('$\mathrm{log_{10}(E/GeV)}$')
> p.ylabel('counts')
> p.title('energy spectrum')
> p.savefig('foo.pdf')
> p.savefig('foo.eps')
> 
> I can report that the rendering of the pdf file is correct, when I set
> the pdf.fonttype to 3. Than everything looks good :-)

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.

> 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.

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 Biester wrote:
> Hi,
>
> I use matplotlib frequenctly on Python 2.4.x. . Recently changed to 
> Python 2.5.1 (upgraded to numpy 1.0.4, matplotlib 0.91.2, scipy 0.6).
>
> The Tkinter graphics does not work anymore. I tried the code snippet 
> below and got a blank window and message box:
>
> python.exe   unknown software exception.
>
>
> I use Windows XP SP2.
>
> Any comments on this are very much appreciated.
Hello Michael,

I tried your sample code on my system and it worked as expected.  I am 
using a slightly older version of numpy ('1.0.3.1').

Here is my system:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\jim.vickroy\My Documents\projects>python
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import numpy
 >>> numpy.__version__
'1.0.3.1'
 >>> import matplotlib
 >>> matplotlib.__version__
'0.91.2'
 >>>

-- jv
>
> Best regards
>
> Michael
>
> ----------------------------------
> import pylab as py
> import numpy as num
>
> t = num.arange(0.0, 2.0, 0.01)
> s = num.sin(2*num.pi*t)
>
> py.figure()
> py.plot(t, s, linewidth=1.0)
>
> py.xlabel('time (s)')
> py.ylabel('voltage (mV)')
> py.title('About as simple as it gets, folks')
> py.grid(True)
>
> py.show()
> --------------------------
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>   

John Hunter wrote:
> On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote:
> 
>> Screens vary.  The screen on my laptop has about 130 dpi. Desktop flat
>> panels will usually have a smaller value than that.  For example, an old
>> "15-inch" flat panel with 1024/768 pixels is actually about 12 inches
>> wide, so dpi=85.  The mpl default 'figure.dpi' of 80 is low; I doubt
> 
> And it is not unusual to have a different DPI in the horizontal and
> vertical directions.  In order to support true physical sizes on the
> screen, we would need to support different dpis in the two directions.

Does any other software actually do this?  I have never seen anything 
with more than a single dpi setting.  What is an example of a display 
with non-square pixels?  And how non-square are they?  I suspect this is 
not something that Alan really needs to worry about.

Eric

More information: this problem reared its ugly head way back in 2005 and 
the same font (orlando.ttf) was the culprit then! ;)

http://sourceforge.net/mailarchive/message.php?msg_id=42E69B61.4060008%40caltech.edu

Also, is it possible you have PyCXX installed in a system-wide location, 
such as /usr/include/CXX or /usr/include/python2.5/CXX ?  If so, the 
compiler might be included those headers, but building with the 
matplotlib-included ones, causing all kinds of craziness.  Try 
uninstalling pycxx and rebuilding matplotlib and see if that solves things.

Cheers,
Mike

Michael Droettboom wrote:
> I'll also give a "blanket" answer to these sorts of gremlins:
> 
>   Remove the "build" directory in the source tree
>   Remove site-packages/matplotlib (usually in 
> /usr/lib/python2.5/site-packages)
>   Rebuild everything
> 
> Cheers,
> Mike
> 
> Michael Droettboom wrote:
>> It also may be of interest which version of freetype you have installed.
>>
>> Michael Droettboom wrote:
>>> Another user reported this bug, which I still have been unable to 
>>> reproduce --
>>>
>>> http://sourceforge.net/mailarchive/message.php?msg_id=4794E454.4070700%40bostream.nu 
>>>
>>>
>>> Jorgen tracked it down to a specific font on his system that he was 
>>> able to delete and then things worked.  Unfortunately, when I tried 
>>> the same font on my system, I could not reproduce the error.  Perhaps 
>>> this issue has to do with the *number* of fonts.  Do you have an 
>>> unusually large amount of fonts?
>>>
>>> Cheers,
>>> Mike
>>>
>>> Tiago de Paula Peixoto wrote:
>>>> Hi there.
>>>>
>>>> I'm encountering the following error when importing
>>>> matplotlib.font_manager:
>>>>
>>>> $ python
>>>> Python 2.5.1 (r251:54863, Jan  7 2008, 22:53:42) [GCC 4.2.2 (Gentoo 
>>>> 4.2.2 p1.0)] on linux2
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>>> import matplotlib.font_manager
>>>> python: CXX/cxx_extensions.cxx:1128: virtual 
>>>> Py::PythonExtensionBase::~PythonExtensionBase(): Assertion 
>>>> `ob_refcnt == 0' failed.
>>>> Aborted
>>>>
>>>> I wasn't able to figure out where the problem might be. Could anybody
>>>> help?
>>>>
>>>> My (gentoo) system is the following:
>>>> matplotlib 0.91.2
>>>> python 2.5.1
>>>> GCC 4.2.2
>>>>
>>>> Cheers,
>>>> Tiago
>>>>
>>>
>>
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'll also give a "blanket" answer to these sorts of gremlins:

   Remove the "build" directory in the source tree
   Remove site-packages/matplotlib (usually in 
/usr/lib/python2.5/site-packages)
   Rebuild everything

Cheers,
Mike

Michael Droettboom wrote:
> It also may be of interest which version of freetype you have installed.
> 
> Michael Droettboom wrote:
>> Another user reported this bug, which I still have been unable to 
>> reproduce --
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=4794E454.4070700%40bostream.nu 
>>
>>
>> Jorgen tracked it down to a specific font on his system that he was 
>> able to delete and then things worked.  Unfortunately, when I tried 
>> the same font on my system, I could not reproduce the error.  Perhaps 
>> this issue has to do with the *number* of fonts.  Do you have an 
>> unusually large amount of fonts?
>>
>> Cheers,
>> Mike
>>
>> Tiago de Paula Peixoto wrote:
>>> Hi there.
>>>
>>> I'm encountering the following error when importing
>>> matplotlib.font_manager:
>>>
>>> $ python
>>> Python 2.5.1 (r251:54863, Jan  7 2008, 22:53:42) [GCC 4.2.2 (Gentoo 
>>> 4.2.2 p1.0)] on linux2
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> import matplotlib.font_manager
>>> python: CXX/cxx_extensions.cxx:1128: virtual 
>>> Py::PythonExtensionBase::~PythonExtensionBase(): Assertion `ob_refcnt 
>>> == 0' failed.
>>> Aborted
>>>
>>> I wasn't able to figure out where the problem might be. Could anybody
>>> help?
>>>
>>> My (gentoo) system is the following:
>>> matplotlib 0.91.2
>>> python 2.5.1
>>> GCC 4.2.2
>>>
>>> Cheers,
>>> Tiago
>>>
>>
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

> On Jan 31, 2008 9:09 AM, Alan G Isaac <ai...@am...> wrote:
>> So, to take an example, suppose I set the figsize=(6,4.5)
>> and dpi = 80.  Then I will get a 480px by 360px figure. 
>> So if this displays on a 120 dpi monitor it will display 
>> as roughly 4" by 3".  And if I print it unmodified to a 300 
>> dpi printer, it will only be about 1.6" by 1.2". 
>> Is that about right? 


On Thu, 31 Jan 2008, John Hunter apparently wrote:
> Probably not.  It will depend on the backend.  For example, if you 
> save in PS or EPS, the dpi is ignored and the vector graphics will be 
> sent to the printer and should print in true figure sizes.  If you 
> print png to the printer, I suspect what happens will depend on the 
> software you are using to print and the printer driver, since the png 
> will have to be converted into some language the printer understands. 


But is the first part right?
(That the PNG would print at 4" by 3" on a 120dpi monitor.)
That seems to match everything said so far on this thread.

This is actually what I need to have a good feel for right now.

Thank you,
Alan Isaac

It also may be of interest which version of freetype you have installed.

Michael Droettboom wrote:
> Another user reported this bug, which I still have been unable to 
> reproduce --
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=4794E454.4070700%40bostream.nu
> 
> Jorgen tracked it down to a specific font on his system that he was able 
> to delete and then things worked.  Unfortunately, when I tried the same 
> font on my system, I could not reproduce the error.  Perhaps this issue 
> has to do with the *number* of fonts.  Do you have an unusually large 
> amount of fonts?
> 
> Cheers,
> Mike
> 
> Tiago de Paula Peixoto wrote:
>> Hi there.
>>
>> I'm encountering the following error when importing
>> matplotlib.font_manager:
>>
>> $ python
>> Python 2.5.1 (r251:54863, Jan  7 2008, 22:53:42) 
>> [GCC 4.2.2 (Gentoo 4.2.2 p1.0)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> import matplotlib.font_manager
>> python: CXX/cxx_extensions.cxx:1128: virtual Py::PythonExtensionBase::~PythonExtensionBase(): Assertion `ob_refcnt == 0' failed.
>> Aborted
>>
>> I wasn't able to figure out where the problem might be. Could anybody
>> help?
>>
>> My (gentoo) system is the following:
>> matplotlib 0.91.2
>> python 2.5.1
>> GCC 4.2.2
>>
>> Cheers,
>> Tiago
>>
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Another user reported this bug, which I still have been unable to 
reproduce --

http://sourceforge.net/mailarchive/message.php?msg_id=4794E454.4070700%40bostream.nu

Jorgen tracked it down to a specific font on his system that he was able 
to delete and then things worked.  Unfortunately, when I tried the same 
font on my system, I could not reproduce the error.  Perhaps this issue 
has to do with the *number* of fonts.  Do you have an unusually large 
amount of fonts?

Cheers,
Mike

Tiago de Paula Peixoto wrote:
> Hi there.
> 
> I'm encountering the following error when importing
> matplotlib.font_manager:
> 
> $ python
> Python 2.5.1 (r251:54863, Jan  7 2008, 22:53:42) 
> [GCC 4.2.2 (Gentoo 4.2.2 p1.0)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import matplotlib.font_manager
> python: CXX/cxx_extensions.cxx:1128: virtual Py::PythonExtensionBase::~PythonExtensionBase(): Assertion `ob_refcnt == 0' failed.
> Aborted
> 
> I wasn't able to figure out where the problem might be. Could anybody
> help?
> 
> My (gentoo) system is the following:
> matplotlib 0.91.2
> python 2.5.1
> GCC 4.2.2
> 
> Cheers,
> Tiago
> 

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi there.

I'm encountering the following error when importing
matplotlib.font_manager:

$ python
Python 2.5.1 (r251:54863, Jan  7 2008, 22:53:42) 
[GCC 4.2.2 (Gentoo 4.2.2 p1.0)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib.font_manager
python: CXX/cxx_extensions.cxx:1128: virtual Py::PythonExtensionBase::~PythonExtensionBase(): Assertion `ob_refcnt == 0' failed.
Aborted

I wasn't able to figure out where the problem might be. Could anybody
help?

My (gentoo) system is the following:
matplotlib 0.91.2
python 2.5.1
GCC 4.2.2

Cheers,
Tiago

-- 
Tiago de Paula Peixoto <ti...@fo...>

On Jan 31, 2008 9:09 AM, Alan G Isaac <ai...@am...> wrote:

> So, to take an example, suppose I set the figsize=(6,4.5)
> and dpi = 80.  Then I will get a 480px by 360px figure.
> So if this displays on a 120 dpi monitor it will display
> as roughly 4" by 3".  And if I print it unmodified to a 300
> dpi printer, it will only be about 1.6" by 1.2".
>
> Is that about right?

Probably not.  It will depend on the backend.  For example, if you
save in PS or EPS, the dpi is ignored and the vector graphics will be
sent to the printer and should print in true figure sizes.  If you
print png to the printer, I suspect what happens will depend on the
software you are using to print and the printer driver, since the png
will have to be converted into some language the printer understands.

On Wed, 30 Jan 2008, "Wayne E. Harlan" apparently wrote:
> The figure size determines the eventual size of the figure 
> where it will be displayed.  You should set that with 
> "figsize=(x,y)" before you actually plot.  Then, and very 
> importantly, you should set the DPI for the medium where 
> you are viewing the figure.

So, to take an example, suppose I set the figsize=(6,4.5)
and dpi = 80.  Then I will get a 480px by 360px figure.
So if this displays on a 120 dpi monitor it will display
as roughly 4" by 3".  And if I print it unmodified to a 300 
dpi printer, it will only be about 1.6" by 1.2".

Is that about right?

Thank you,
Alan Isaac

Bernhard Voigt wrote:
> I've been trying to use the STIXGeneral font that comes with
> matplotlib (my version is 0.91.1). It's rendered ok on the screen,
> however, when saving the fig as an eps file my postscript processor
> (ghostscript) can't read the font information included in the eps file
> (ps.fonttype 42 in config file).

I can reproduce that problem here.  As a workaround, however, 
ps.fonttype 3 seems to work for me, plus has the advantage of a much 
smaller eps file.

> I wonder if it's a bug in the
> conversion to ttf, that has been applied to the STIX font.

Possibly.  It could also be a buffer overflow, since that font is on the 
large side.  I'll have to look into that.

> Saving to
> pdf format works, but the ticklabels are not rendered correctly,
> there's too much space between the glyphs and they are overlapping
> with the axes. The title looks good, though.

The PDF from mathtext_demo.py looks fine to me.  Can you send a short 
plot that exhibits this behavior?

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, 31 Jan 2008, John Hunter apparently wrote:
> And it is not unusual to have a different DPI in the 
> horizontal and vertical directions.  In order to support 
> true physical sizes on the screen, we would need to 
> support different dpis in the two directions. 

Does that mean that one should expect font-shape distortion
when PNGs are displayed onscreen?  And maybe even that a
square figure will not display as square? If not, why not?

I've never had to think about this before: it seems an
odd nightmare for some kinds of online publication
(e.g., scientific journals using HTML based publication
formats).

Thank you,
Alan Isaac

On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote:

> Screens vary.  The screen on my laptop has about 130 dpi. Desktop flat
> panels will usually have a smaller value than that.  For example, an old
> "15-inch" flat panel with 1024/768 pixels is actually about 12 inches
> wide, so dpi=85.  The mpl default 'figure.dpi' of 80 is low; I doubt

And it is not unusual to have a different DPI in the horizontal and
vertical directions.  In order to support true physical sizes on the
screen, we would need to support different dpis in the two directions.

JDH