matplotlib-devel Mailing List for matplotlib

Leon Barrett wrote:
> I found a bug in the Axes3D code for making 3D plots. I created a simple 
> patch to fix it. I then submitted a bug to the tracker more than a week 
> ago. However, it seems to have gone unnoticed, so I am sending this 
> information to the mailing list, which seems to be more active than the 
> bug tracker.
> 
> To view the bug, go here:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1798196&group_id=80706&atid=560720
> 

Leon,

Thanks.  I applied your changes in svn 3902 and 3903.  Putting bug 
reports and patches in the tracker is good, but it is advisable to send 
mail to the list at the same time.  We are not doing a good job of 
keeping on top of reports in the tracker.

Eric

It turns out (thanks to Darren for the debug info) that AFM files do not
exist for all fonts in all current TeX distributions, so I have modified
the pdf backend to not use them. This loses some information that is
required by the pdf spec (such as the x-height and stem widths of the
embedded font) but at least in some tests Preview.app and Adobe Reader
don't seem to mind.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

If someone decides to poke around in the 3D plotting files in response 
to Leon's efforts, there's another fix posted a while back which was not 
applied:
<http://sourceforge.net/mailarchive/forum.php?thread_name=d8cf9020703071339y43354eaerbfa1a47d272e5d26%40mail.gmail.com&forum_name=matplotlib-users>
I tried this at the time and it worked with no obvious side effects.

Gary R.

I found a bug in the Axes3D code for making 3D plots. I created a simple 
patch to fix it. I then submitted a bug to the tracker more than a week 
ago. However, it seems to have gone unnoticed, so I am sending this 
information to the mailing list, which seems to be more active than the 
bug tracker.

To view the bug, go here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1798196&group_id=80706&atid=560720

-- 
Leon Barrett
1932 Hearst Ave. Apt. F
Berkeley, CA 94709
le...@ba...
http://leon.barrettnexus.com/
home: 510-665-5428
cell: 217-257-4163

Darren Dale <dd...@co...> writes:

> I tried the following, with the latest svn checkout and usetex=True:
> plot([1,2])
> savefig('test.pdf')
> and I get an error, the tail end is:
[...]
> --> 503         fh = open(fontinfo.afmfile, 'rb')
> IOError: [Errno 2] No such file or directory: ''

Could you update from svn, set verbose.level to debug, run your example
again, and email me the output? Also, which TeX distribution do you
have?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi Jouni,

On Thursday 13 September 2007 02:38:25 am Jouni K. Sepp=E4nen wrote:
> The usetex support in pdf is now a little better, so I am enabling it
> now. At least it is more entertaining than NotImplementedError...
>
> I have fixed some of the biggest problems (the broken font embedding
> causing crashes of Preview.app, and the lack of virtual font support).
> It still makes some assumptions about the TeX distribution: you need
> kpsewhich and pdftex.map, so on TeX Live or (I presume) teTeX you are
> fine, but I have no idea about Windows.
>
> Transformations of Type-1 fonts are not implemented, so if you try to
> use $\alpha$ with Times, TeX typesets an alpha from Symbol and slants
> it, but you get the non-slanted version. Fixing this (and adding
> subsetting support) probably requires a complete Type-1 parser.
>
> There is support for baseline alignment, but it is based on finding the
> baseline of the lowest character, so subscripts will throw it off. A
> good solution will require some TeX magic.
>
> Reports of bugs (or successes) are welcome.

I tried the following, with the latest svn checkout and usetex=3DTrue:

plot([1,2])
savefig('test.pdf')

and I get an error, the tail end is:

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_pdf.py in=20
writeFonts(self)
    468             elif filename.endswith('.pfb') or=20
filename.endswith('.pfa'):
    469                 # a Type 1 font; limited support for now
=2D-> 470                 fontdictObject =3D self.embedType1(filename,=20
self.fontInfo[Fx])
    471             else:
    472                 realpath, stat_key =3D get_realpath_and_stat(filena=
me)

/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_pdf.py in=20
embedType1(self, filename, fontinfo)
    501             fh.close()
    502
=2D-> 503         fh =3D open(fontinfo.afmfile, 'rb')
    504         matplotlib.verbose.report(
    505             'Reading metrics from ' + fontinfo.afmfile, 'debug')

IOError: [Errno 2] No such file or directory: ''


Darren

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?

Regards
St=E9fan

Bill Baxter wrote:
> 
> On 9/24/07, *Eric Firing*
> <ef...@ha...
> <mailto:ef...@ha...>> wrote:
> 
>     John et al.,
> 
>     "Agg 2.5 will ship with a libsigc++ license that will allow us to treat
>     the code as MIT X11 unless the code is pulled out, allowing Antigrain to
>     be used internally for Silverlight and allowing them to license
>     Antigrain for other customers."
> 
>     I found the above quote on this page:
>     http://www.mono-project.com/Moonlight
> 
>     I don't understand it; does it mean that we, too, can continue using
>     future versions of Agg?
> 
> Weird.  It reads to me more like they struck some sort of deal whereby
> the code can be used as MIT X11 as long as it's an internal part of
> Silverlight, but if removed from Silverlight, then it will revert to the
> current GPL/commercial dual license.

Unfortunately, that's not how these licenses work. Moonlight is LGPL/commercial
dual-licensed. If they intend to continue that way and incorporate Agg 2.5 into
it under special terms from Maxim, then Moonlight will still be LGPL/commercial,
*including* Agg 2.5. The LGPL allows one to extract a part of the LGPLed work
and use it separately under the LGPL license. If Maxim agrees to let Agg 2.5 be
used in an LGPLed Moonlight, then he can't then require that Agg 2.5 will only
be used in the context of Moonlight. Someone is confused, here (and it's not me
:-)).

Also unfortunately, this has no bearing on matplotlib. matplotlib still can't
use Agg 2.5 under an MIT/X11-style license. Asking Maxim for a special license
won't help because that license can't be MIT/X11 or anything near as free as
matplotlib's license without his giving away Agg 2.5 as a whole under that free
license.

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

Hi!

I'm writing a gtk application that uses matplotlib heavily for data visualisation, but all the time consuming redrawing of the figure canvases took away much of the usability. So I wrote a FigureCanvas that delays redraws until it hasn't seen any new resize_events for a short while. It works much more smoothly on ubuntulinux than on winxp (where many redraws slip through the seams and I'm not sure why that happens), but anyway - tell me what you think! Is this a good solution, or is there a smarter approach?

Cheers!
/Joel

On 9/24/07, Eric Firing <ef...@ha...> wrote:

> Maybe this is the result of the Mono people contacting Maxim as
> suggested by his 10/26 news post here:
> http://www.antigrain.com/news/index.html
>
> "# Current AGG users who are willing to continue using AGG under the old
> terms and conditions are encouraged to contact me and I will consider
> their requests."

This is certainly a possibility for us.  We are still on agg 2.3
actually, so I don't see this as a burning issue, but if we ever need
to upgrade from 2.4 or want upgrade for bugfixes, etc, I will email
Maxim and ask him about licensing options.

JDH

On Saturday 22 September 2007 08:06:56 pm Eike Welk wrote:
> Hi all!
>
> The QT backend (backend_qt.py) does not enter QT's event loop when
> multiple figures were created. It works fine with a single figure
> though.
>
> I have tested this with Suse Linux 10.2.
> matplotlib.__version__ : 0.90.1
>
> I have attached a little test program that illustrates the bug: When
> this program is run, two windows will appear for a split second, and
> the program finishes immediately.
> When lines 10 and 11 are commented out, the program works as expected:
> One window with a figure appears, and the program finishes when the
> window is closed.
>
> The attached patch fixes this bug. It is against the current HEAD in
> trunk.
>
> >From reading the code, the exact same fix should be done in the QT4
>
> backend.

Thank you for the report and for solving the problem. I applied your fix to 
backend_qt and backend_qt4 in svn-3879.

Darren

Bill Baxter wrote:
> 
> On 9/24/07, *Eric Firing* <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
>     John et al.,
> 
>     "Agg 2.5 will ship with a libsigc++ license that will allow us to treat
>     the code as MIT X11 unless the code is pulled out, allowing Antigrain to
>     be used internally for Silverlight and allowing them to license
>     Antigrain for other customers."
> 
>     I found the above quote on this page:
>     http://www.mono-project.com/Moonlight
> 
>     I don't understand it; does it mean that we, too, can continue using
>     future versions of Agg?
> 
> 
> Weird.  It reads to me more like they struck some sort of deal whereby 
> the code can be used as MIT X11 as long as it's an internal part of 
> Silverlight, but if removed from Silverlight, then it will revert to the 
> current GPL/commercial dual license.
> 
> --bb

Maybe this is the result of the Mono people contacting Maxim as 
suggested by his 10/26 news post here: 
http://www.antigrain.com/news/index.html

"# Current AGG users who are willing to continue using AGG under the old 
terms and conditions are encouraged to contact me and I will consider 
their requests."

Eric

On 9/24/07, Eric Firing <ef...@ha...> wrote:
>
> John et al.,
>
> "Agg 2.5 will ship with a libsigc++ license that will allow us to treat
> the code as MIT X11 unless the code is pulled out, allowing Antigrain to
> be used internally for Silverlight and allowing them to license
> Antigrain for other customers."
>
> I found the above quote on this page:
> http://www.mono-project.com/Moonlight
>
> I don't understand it; does it mean that we, too, can continue using
> future versions of Agg?


Weird.  It reads to me more like they struck some sort of deal whereby the
code can be used as MIT X11 as long as it's an internal part of Silverlight,
but if removed from Silverlight, then it will revert to the current
GPL/commercial dual license.

--bb

John et al.,

"Agg 2.5 will ship with a libsigc++ license that will allow us to treat 
the code as MIT X11 unless the code is pulled out, allowing Antigrain to 
be used internally for Silverlight and allowing them to license 
Antigrain for other customers."

I found the above quote on this page: http://www.mono-project.com/Moonlight

I don't understand it; does it mean that we, too, can continue using 
future versions of Agg?

Eric

Sorry, I've sent a corrupted patch. This one should work.

Regards,
Eike.

Hi all!

The QT backend (backend_qt.py) does not enter QT's event loop when 
multiple figures were created. It works fine with a single figure 
though. 

I have tested this with Suse Linux 10.2.
matplotlib.__version__ : 0.90.1

I have attached a little test program that illustrates the bug: When 
this program is run, two windows will appear for a split second, and 
the program finishes immediately.
When lines 10 and 11 are commented out, the program works as expected: 
One window with a figure appears, and the program finishes when the 
window is closed. 

The attached patch fixes this bug. It is against the current HEAD in 
trunk. 

>From reading the code, the exact same fix should be done in the QT4 
backend.

Regards,
Eike.

Michael Droettboom wrote:
> Is the current Mac OS-X version also something to consider? 

I don't think so. You really need to install a newer/better version to 
do anything significant with python on OS-X -- particularly anything 
with a GUI.

John Hunter wrote:
> We don't really need generator
> comprehensions -- in the examples you highlighted I think they were
> used for syntactic convenience, though admittedly in some cases syntax
> conveniences are compelling.

Sure they are, but wouldn't list comprehensions be just as good? at 
least in those cases.

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

> Does anyone have an opinion on how much longer we will support python-2.3?
> Maybe a good guide would be to support the most up-to-date RHEL release,
> as well as the prior release. (At my lab, we haven't updated our RHEL
> computers to version 5 yet, the first to include python-2.4.)

Is the current Mac OS-X version also something to consider?  It's 
currently at 2.3 in 10.4 Tiger.

Cheers,
Mike

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

After removing my build/ and site-packages-matplotlib*, I installed the
most up-to-date svn numpy and matplotlib on a RHEL4 machine. I'm getting
the following errors:

  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/_cm.py",
line 5962, in ?
    cmapdat_r = revcmap(datad[cmapname])
  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/_cm.py",
line 5955, in revcmap
    valnew = [(1.-a, b, c) for a, b, c in reversed(val)]
ValueError: unpack tuple of wrong size

Here is the output of all the reversed(val):


(10, (1.0, 0.63529413938522339, 0.63529413938522339))
(9, (0.90000000000000002, 0.74117648601531982, 0.74117648601531982))
(8, (0.80000000000000004, 0.64705884456634521, 0.64705884456634521))
(7, (0.69999999999999996, 0.64313727617263794, 0.64313727617263794))
(6, (0.59999999999999998, 0.59607845544815063, 0.59607845544815063))
(5, (0.5, 0.74901962280273438, 0.74901962280273438))
(4, (0.40000000000000002, 0.54509806632995605, 0.54509806632995605))
(3, (0.29999999999999999, 0.3803921639919281, 0.3803921639919281))
(2, (0.20000000000000001, 0.26274511218070984, 0.26274511218070984))
(1, (0.10000000000000001, 0.30980393290519714, 0.30980393290519714))
(0, (0.0, 0.25882354378700256, 0.25882354378700256))

I don't get the error with python-2.5. reversed is defined by cbook if
python doesnt have it as a builtin, but cbook yields an (index, tuple)
whereas the builtin yields only the tuple. I changed cbook's reversed to
agree with the python builtin, and made notes in the CHANGELOG and
API_CHANGES.

Darren

On 9/21/07, Darren  Dale <dd...@co...> wrote:

> Does anyone have an opinion on how much longer we will support python-2.3?
> Maybe a good guide would be to support the most up-to-date RHEL release,
> as well as the prior release. (At my lab, we haven't updated our RHEL
> computers to version 5 yet, the first to include python-2.4.)

I think we should continue to support it for a while yet, mainly
because it is easy to do so.  We don't really need generator
comprehensions -- in the examples you highlighted I think they were
used for syntactic convenience, though admittedly in some cases syntax
conveniences are compelling.

I only recently upgraded from 2.3 on my home machine, when I was
trying to get svn traits working.  I am not sure that RHEL should be
our standard though -- shouldn't people be punished for using that
distro anyway <wink>?

A good way to know it's time to deprecate support is when you
accidentally break something and noone notices for a month or two
because noone is actually using it.

JDH

It looks like some syntax introduced in python-2.4 is starting to find its
way into matplotlib:

  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/texmanager.py",
line 113
    + tuple('font.'+n for n in ('family', ) + font_families)
                        ^
SyntaxError: invalid syntax
  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/dviread.py",
line 355
    for ch in special),
      ^
SyntaxError: invalid syntax
  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/config/mpltraits.py",
line 49
    return "one of %s"% ', '.join('%s'%i for i in be)
                                           ^
SyntaxError: invalid syntax
  File
"/usr/lib/python2.3/site-packages/matplotlib-0.90.1_r3867-py2.3-linux-i686.egg/matplotlib/backends/backend_pdf.py",
line 544
    not_None = (ch for ch in range(256)
                     ^
SyntaxError: invalid syntax


Does anyone have an opinion on how much longer we will support python-2.3?
Maybe a good guide would be to support the most up-to-date RHEL release,
as well as the prior release. (At my lab, we haven't updated our RHEL
computers to version 5 yet, the first to include python-2.4.)

Darren

This seems to be related to the change to pickle cache the entire 
FontManager class.  If you delete ~/.matplotlibrc/fontManager.cache, the 
font.size setting takes effect.

I made a small change in r3861 that should fix this problem.

Cheers,
Mike

Darren Dale wrote:
> It appears that relative font sizing is broken in svn. It used to be possible 
> to do this:
> 
> from matplotlib import rcParams
> rcParams['font.size']=6
> rcParams['xtick.labelsize']='small'
> import pylab
> pylab.plot([1,2])
> pylab.text(0.1, 1.75, 'look how small I am compared to the ticks')
> pylab.show()
> 
> and any of the various text sizes like ticklabels, axis labels, titles, etc, 
> would be sized relative to font.size. It looks like relative sizes are no 
> longer scaled to font.size, but some fixed value. Does anyone know what has 
> changed?
> 
> Thanks,
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

It appears that relative font sizing is broken in svn. It used to be possible 
to do this:

from matplotlib import rcParams
rcParams['font.size']=6
rcParams['xtick.labelsize']='small'
import pylab
pylab.plot([1,2])
pylab.text(0.1, 1.75, 'look how small I am compared to the ticks')
pylab.show()

and any of the various text sizes like ticklabels, axis labels, titles, etc, 
would be sized relative to font.size. It looks like relative sizes are no 
longer scaled to font.size, but some fixed value. Does anyone know what has 
changed?

Thanks,
Darren

In case anyone is interested, it looks like the new config package is working 
with traits 3. This morning I uninstalled my enthought-2.whatever packages 
and installed etsconfig-2.1 and traits-3 from enthought's svn trunk (using 
the usual python setup.py install, not easy_install). backend_driver.py ran 
without errors.

Darren

Hi, here a message I sent a while ago, but I hanen't seen it on the
ML, so here it is again, in case.

Thanks,
David Douard


---------------

Here is a simple patch that allow to make legend and its compnents
(texts, patches and lines) pickable for real.

The goal was to make this work (may be added to examples in mpl):

from pylab import *

N=100

props = dict( alpha=0.5, faceted=False )

fig=figure()

handles = []
colours = ['red', 'green', 'blue', 'magenta', 'cyan', 'yellow']

for colour in colours:
    x, y = rand(2,N)
    s = 400.0 * rand(N)
    handles.append(scatter(x, y, c=colour, s=s, picker=True, **props))

l = legend(handles, colours, )

grid(True)

for lb in l.get_texts():
    lb.set_picker(True)

def pick(event):
    a = event.artist
    if isinstance(a, matplotlib.text.Text):
        name = event.artist.get_text()
        h = handles[colours.index(name)]
        h.set_visible(not h.get_visible())
        draw()

fig.canvas.mpl_connect('pick_event', pick)
show()

 

PS: note that I am not on the mpl-devel  mailing-list. Please Cc me
back in case of reply.


-- 
David Douard                        LOGILAB, Paris (France), +33 1 45 32 03 12
Formations Python, Zope, Debian :   http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique :         http://www.logilab.fr/science