matplotlib-devel Mailing List for matplotlib

Carl,
I have made a few changes in svn to facilitate testing cairo with 
backend_driver (and to fix a bug that turned up), and I will do a bit 
more on this later today or tomorrow. The result of a quick pass 
through the backend_driver test with png output is quite encouraging, 
though. There are some bugs in string placement, image handling, and 
clipping, but most things work, including mathtext. Default fonts seem 
to be different.
Eric
Carl Worth wrote:
> On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote:
>> On 7/5/07, Carl Worth <cw...@cw...> wrote:
>>> I don't know if there's anything special about the PostScript output
>>> you're currently producing that wouldn't make it acceptable to use
>>> cairo's PostScript output directly. But even if you just want code,
>>> it's inside cairo under the LGPL.
>> I looked at cairo when we first started with the postscript backend,
>> but in the bad old days it was just a raster dump. I understand it
>> has come a long way since.
[...]

On Thu, 5 Jul 2007 14:46:13 -0500, "John Hunter" wrote:
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
For what it's worth, I think I'd be inclined to agree with you
there. If your existing code is working just fine, then switching to
cairo is just more work. But if you do start having to do any serious
maintenance, then you might want to reconsider.
> http://www.scipy.org/License_Compatibility
Thanks, John, for sharing this essay. Please allow me to respond to a
few points:
	In my experience, the benefits of collaborating with the
	private sector are real, whereas the fear that some private
	company will "steal" your product and sell it in a proprietary
	application leaving you with nothing is not.
In my experience, there is real harm that can come when proprietary
modifications to a license made available under a permissive license
are not contributed back. An extremely clear case is that of the X
Window System which went through a period of several independent
software vendors trying to out-compete each other on their own
proprietary modifications to the system, (resulting in the near death
of the system altogether).
I've had some discussions with Jim Gettys about that process and how
the MIT license for X has played out over the years. You argue that a
project most needs the extra users provided by a permissive license
during its formative years until it reaches critical mass and the
network effects kick in. Jim actually argues the point differently and
says that the extra protections of the GPL are most necessary during
the formative period, but not at all needed once the project reaches
critical mass. So I've heard him express that he wishes there were a
way to allow a project to grow under the GPL and then change to
something like the MIT license once it reaches critical
mass.
	There is a lot of GPL code in the world, and it is a constant
	reality in the development of matplotlib that when we want to
	reuse some algorithm, we have to go on a hunt for a non-GPL
	version.
So that's a cost that you need to weigh against the decision to not be
able to accept any GPL code into your project. But I think the fact
that there _is_ a lot of GPL code in the world is a strong argument
against your original thesis that a license more permissible than the
GPL is necessary to bootstrap a free software project to critical
mass. There _is_ a lot of GPL code, which means there _are_ a lot of
users of that code, and a lot of those users are businesses that don't
have a problem using, (and modifying, and contributing back to), GPL
code.
	There are two unpalatable options. 1) Go with GPL and lose the
	mind-share of the private sector 2) Forgo GPL code and retain
	the contribution of the private sector.
You've chosen (2) along with a decision to try to campaign authors of
GPL code to relicense their code as BSD/MIT (ish) whenever you want to
use it. I would guess you'll find that quite difficult in many cases,
(I don't agree that the GPL is most often chosen without intention
just because it is "famous").
I think an easier route to take path (2) is to use the LGPL for your
library, and then only have to convince authors to re-license the
subset of their GPL application code as LGPL that you're actually
interested in incorporating into your library. I would predict that
you will be more successful at that more often than convincing people
to relicense GPL to BSD/MIT (ish).
You only bring the LGPL up at the end of your essay as almost an
afterthought and dismiss it with a very vague, "but many companies are
still loath to use it out of legal concerns". Do you have actual
evidence to point to for that?
It would be simpler if there were direct experiments we could run to
measure some of these things, but there aren't, (and conditions do
continue to change). My experience with the cairo project suggests
that we've been able to achieve a very successful library
implementation, (with plenty of "corporate" contribution), with an
LGPL (and MPL) license.
	This is a very tough decision because their is a lot of very
	high quality software that is GPL and we need to use it;
Network effects are strong---when they're good, don't fight them. :-)
And I've even been annoyed enough with having to get code relicensed
from GPL to LGPL+MPL for use in cairo that I'm thinking the next
library I invent might be simply GPL from the beginning.
Which brings me to my final point. I think it's very interesting (and
worthwhile) to debate license decisions like this. But at the end of
the day, when a project chooses a free software license, and that
project becomes at all "established" it's probably rarely a good idea
to change that license. I just don't think that it's right to engage a
community with one set of ground rules, and then to go and change
those rules out from under the community.
So, even if the current license from matplotlib would allow you to
easily change from it to the LGPL (which I think it does), I wouldn't
make any argument that you should think of changing the project
license.
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
Definitely not converting all text to raster, (unless someone's using
an ancient version of cairo).
-Carl

On Thu, 5 Jul 2007 13:26:22 -0500, "John Hunter" wrote:
> On 7/5/07, Carl Worth <cw...@cw...> wrote:
> > I don't know if there's anything special about the PostScript output
> > you're currently producing that wouldn't make it acceptable to use
> > cairo's PostScript output directly. But even if you just want code,
> > it's inside cairo under the LGPL.
>
> I looked at cairo when we first started with the postscript backend,
> but in the bad old days it was just a raster dump. I understand it
> has come a long way since.
Yes, it's definitely a _lot_ better than that now. As of any recent
release of cairo, (1.4.x), you will probably get all-vector output for
the kinds of things I would expect matplotlib to do.
If you do hit something that requires a raster-based fallback in
cairo, (translucence or similar), the current releases of cairo do
still compute the fallback by doing full-page rasterization. But
there's a patch already put together, (by the expert Adrian Johnson),
that makes cairo do rasterization for only the minimal necessary
region, (so expect that in cairo 1.6 in the future).
> mpl's postscript backend supports latex expressions in PS output,
> which requires a fair amount of complex trickery in the postscript
> backend, though we we could probably do it with embedded rasters in
> cairo.
Embedding latex expressions is really cool. If you do try something
like this with cairo and find that you wish cairo would do something
that it can't, then please let me know.
> The postscript backend is also standalone with no dependencies
> other than mpl and numpy, and adding cairo to the mix might be a bit
> difficult for across platforms for some users (though this appears to
> have gotten a lot better too).
Yes, cairo should work extremely well across platforms, (and
particularly the "generic" backends like the image, PDF, PostScript,
and SVG backends). The only outstanding platform-specific issues are in
display-device-specific backends such as in cairo's quartz backend,
(but even it does work extremely well---just not quite perfectly---and
the mozilla people are working hard to complete it).
> LGPL means we cannot reuse the code.
That's your choice of course.
As far as type3 goes, there's really nothing special there. It would
be just as easy (or easier) to just read the PostScript language
reference and implement things directly as compared to reading cairo's
code. That's all I did to write it originally, and it's not hard at
all.
Now, some of the other font subsetting work in cairo is a bit more
sophisticated. Adrian Johnson has done most of that, so he would
probably be the person you would need to ask if you would like the
code to be made available under a more liberal licence than the LGPL,
(or the Mozilla Public License as cairo is currently made available
under either of those).
> While I like the idea of using cairo for both raster and vector
> outputs in principle because it offloads a lot of work onto a large
> and well supported project, it would probably take a fair amount of
> work to get all of mpl's functionality into the cairo backend (I don't
> know this since I have not tested the backend for some time, but does
> it support, for example unicode_demo, mathtext_demo, usetex, and
> image_demo ?).
It doesn't look to me like there's a lot of missing work.
Here are the results from unicode_demo:
	http://www.cworth.org/matplotlib/
To summarize, all of the PNG, PostScript, PDF, and SVG output looks
fine from the cairo backend. Meanwhile, the PDF backend, (as of
0.87.7) seems to generate broken output for the accented characters,
and the SVG backend doesn't position/scale the text correctly.
Cairo's PDF and PostScript output is smaller than matplotlib's native
output, (factor of 2.75), while cairo's SVG output is a fair amount
larger than matplotlib's, (factor of 11), since it's embedding all of
the text glyphs, (which could be either good or bad depending on what
you really want).
I didn't seem to have any usetex demo installed with the Debian 0.87.7
package of python-matplotlib-doc, and with both mathtext_demo and
image_demo I got the following inscrutable error messages:
	/usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:329:
	UserWarning: cairo with Numeric support is required for
	_draw_mathtext()
	/usr/lib/python2.4/site-packages/matplotlib/backends/backend_cairo.py:162:
	UserWarning: cairo with Numeric support is required for draw_image()
Does anybody know what that could mean? I have no idea what "cairo
with Numeric support" is. Is it perhaps something specific to the
pycairo python bindings of cairo?
-Carl

Ken McIvor wrote:
>> This qualifies as a wx bug, doesn't it?
> I believe so. I'll file it.
I agree - a segfault is ALWAYS a bug.
>> If wx doesn't retain the reference, then instead of a segfault 
>> shouldn't it raise an exception?
> 
> I'd expect wx.GetApp() to work like the rest of wxPython and always 
> return the wx.App instance.
If a wx.App has not been created, it returns None:
 >>> import wx
 >>> wx.GetApp()
 >>> a = wx.GetApp()
 >>> print a
None
Which is probably what it should do if the wxApp() has been deleted.
In any case, you can only create one wxApp per program instance, and it 
can not be destroyed and re-started, so keeping a global instance around 
is probably the way to go.
-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...

On Jul 5, 2007, at 3:48 PM, Eric Firing wrote:
>
> This qualifies as a wx bug, doesn't it?
I believe so. I'll file it.
> If wx doesn't retain the reference, then instead of a segfault 
> shouldn't it raise an exception?
I'd expect wx.GetApp() to work like the rest of wxPython and always 
return the wx.App instance.
This has been fixed in revision 3463.
Ken

Ken McIvor wrote:
> On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
>>
>> Interesting. I don't get that, but I do get some random segfaults (I
>> got lucky the first time I tested).
> 
> It looks like wxPython doesn't retain a reference to the wxApp PyObj for 
> you:
> 
> kmcivor@400exp209:~/Projects/matplotlib-svn$ pythonw
> Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
> [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import wx
> >>> app = wx.PySimpleApp()
> >>> del app
> >>> wx.GetApp()
> Segmentation fault
This qualifies as a wx bug, doesn't it? If wx doesn't retain the 
reference, then instead of a segfault shouldn't it raise an exception?
Eric

That is at least something to go by. ;)
Thanks,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> And here is the result of the script modified for gtk:
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
> 55352 55417
> *** <type 'gtk.gdk.Colormap'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
> *** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
> *** <type 'gtk.gdk.Pixmap'>
> *** <type 'gtk.Tooltips'>
> *** <type 'gtk.Label'>
> *** <type 'gtk.Window'>
> *** <type 'gtk.VBox'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
> 55352 55421
> *** <type 'gtk.gdk.Colormap'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <class 'gtk._gtk.WidgetFlags'>
> *** <type 'gtk.gdk.Window'>
> *** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
> *** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
> *** <type 'gtk.gdk.Pixmap'>
> *** <type 'gtk.Tooltips'>
> *** <type 'gtk.Label'>
> *** <type 'gtk.Window'>
> *** <type 'gtk.VBox'>
>
> uncollectable list: []
>
> Eric
>

Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if 
that makes a difference.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script? 
>> This is how I was finding object leaks before. It takes a single 
>> commandline argument that is the number of iterations. Can you send 
>> me the outputs from 1 and 2 iterations? That way we should be able 
>> to see what type of object is being leaked, which is a good first step.
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
> 75891 76010
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
> efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer 
> Dell424 could not be loaded.
> GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
> could not be loaded.
> 75891 76014
> *** <class 'wx._core.PySimpleApp'>
> *** <class 'wx._core._wxPyDeadObject'>
>
> uncollectable list: []
>
>
> Eric
>

On Jul 5, 2007, at 2:13 PM, Michael Droettboom wrote:
>
> Interesting. I don't get that, but I do get some random segfaults (I
> got lucky the first time I tested).
It looks like wxPython doesn't retain a reference to the wxApp PyObj 
for you:
	kmcivor@400exp209:~/Projects/matplotlib-svn$ pythonw
	Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
	[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import wx
	>>> app = wx.PySimpleApp()
	>>> del app
	>>> wx.GetApp()
	Segmentation fault
> I'm awfully surprised that wx.GetApp() would return an iterator, as 
> you
> are getting, so maybe it's corruption of some sort?
My guess is that Eric got lucky and ob_type was pointing to the 
listiterator's C type instance.
> Since I didn't want to just put the wxapp global variable back in, 
> I assigned it to the figure that creates it, therefore stick around 
> as long as the figure does. (Is that the correct thing for its 
> lifetime?)
I don't think this will work if you create two figures, destroy the 
first one, and then create another figure. Once created, the wxApp 
needs to exist for the life of the python process. I'll go ahead an 
put the global variable back in.
> Also, I'm a little puzzled by this code in show() in backend_wx.py:
>
> wxapp = wx.GetApp()
> if wxapp is not None:
> # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
> imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
> if imlr():
> wxapp.MainLoop()
>
> If I'm reading this correctly, shouldn't it be "if not imlr()"?
Yes, it should be. I'll try to code with my eyes open from now on. :-/
Ken

Michael Droettboom wrote:
> Interesting...
> 
> When you get a chance, would you mind running the attached script? This 
> is how I was finding object leaks before. It takes a single commandline 
> argument that is the number of iterations. Can you send me the outputs 
> from 1 and 2 iterations? That way we should be able to see what type of 
> object is being leaked, which is a good first step.
And here is the result of the script modified for gtk:
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 1
55352 55417
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>
uncollectable list: []
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_gtk.py 2
55352 55421
*** <type 'gtk.gdk.Colormap'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FileChooserDialog'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <class 'gtk._gtk.WidgetFlags'>
*** <type 'gtk.gdk.Window'>
*** <class 'matplotlib.backends.backend_gtk.FigureCanvasGTK'>
*** <class 'matplotlib.backends.backend_gtk.NavigationToolbar2GTK'>
*** <type 'gtk.gdk.Pixmap'>
*** <type 'gtk.Tooltips'>
*** <type 'gtk.Label'>
*** <type 'gtk.Window'>
*** <type 'gtk.VBox'>
uncollectable list: []
Eric

On Thursday 05 July 2007 03:46:13 pm John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
> > Do you agree that it is still an open question whether it's better to
> > spend time improving the matplotib PS backend, or to fix (if possible)
> > the issues with matplotlib's Cairo integration? It does ultimately come
> > down to a tradeoff: an additional dependency vs. extra maintenance
>
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
It was a fair amount of work figuring out how to support latex. Jouni started 
work on a dvi parser, see dviread.py in matplotlib/lib/matplotlib, which 
could greatly simplify the gymnastics we currently use to support latex in ps 
output. If dviread were to be further developed, latex could also be used in 
conjunction with the pdf backend (Jouni's reason for starting dviread), the 
svg backend, and I guess it would work with cairo as well. But making dviread 
robust will probably take more work than options 1 or 2, so it is probably 
best to pursue one of those options for now.
> While I would love to see cairo become a full featured backend, and
> for there to be additional GUI support like tkcairo, wxcairo, etc, we
> are a lot farther from that goal than we are to getting the font sizes
> down in the existing postscript backend. And I like the fact the mpl
> is completely BSD-ish -- relying on a core component which is LGPL
> would be a step back in my book, though having it as an option would
> be great.
Why can't we all just get along?
> Do you mean mathtext or usetex? - The former is mpl's own math layout
> using the cm*.ttf files, and should work like any other text in the
> file. The latter uses tex and dvipng rasters (at least in agg), but I
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
I think he is right, gtkcairo converts mathtext to rasters. usetex is not 
support in gtkcairo.
Darren

Michael Droettboom wrote:
> Interesting...
> 
> When you get a chance, would you mind running the attached script? This 
> is how I was finding object leaks before. It takes a single commandline 
> argument that is the number of iterations. Can you send me the outputs 
> from 1 and 2 iterations? That way we should be able to see what type of 
> object is being leaked, which is a good first step.
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 1
75891 76010
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>
uncollectable list: []
efiring@manini:~/programs/py/mpl/tests$ python memleak_gui_wx.py 2
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer Dell424 
could not be loaded.
GnomePrintCupsPlugin-Message: The ppd file for the CUPS printer pslj4m 
could not be loaded.
75891 76014
*** <class 'wx._core.PySimpleApp'>
*** <class 'wx._core._wxPyDeadObject'>
uncollectable list: []
Eric

John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
>
>
>> Do you agree that it is still an open question whether it's better to
>> spend time improving the matplotib PS backend, or to fix (if possible)
>> the issues with matplotlib's Cairo integration? It does ultimately come
>> down to a tradeoff: an additional dependency vs. extra maintenance
>
> The postscript backend as it stands is in good shape, and is full
> featured (Darren can tell you how much work he has put into supporting
> and enhancing the latex support). The last major issue with it is the
> font size issue, and with your help a solution is on the horizon. So
> it is definitely a good use of time to fix this last bit. It doesn't
> sound like your "option 2" is a ton of work, but correct me if I'm
> wrong.
No, not a ton of work. And this context is helpful.
>
> While I would love to see cairo become a full featured backend, and
> for there to be additional GUI support like tkcairo, wxcairo, etc, we
> are a lot farther from that goal than we are to getting the font sizes
> down in the existing postscript backend. And I like the fact the mpl
> is completely BSD-ish -- relying on a core component which is LGPL
> would be a step back in my book, though having it as an option would
> be great.
>
> http://www.scipy.org/License_Compatibility
Agreed.
> Do you mean mathtext or usetex? - The former is mpl's own math layout
> using the cm*.ttf files, and should work like any other text in the
> file. The latter uses tex and dvipng rasters (at least in agg), but I
> don't think it is supported in cairo. So I am not sure where these
> rasters are coming from, unless cairo is converting all text to
> rasters.
mathtext_demo.py -- It originally looked like the math text was 
rasterized, but the tick labels are not. On closer inspection, it seems 
all the text is rasterized. The fonts are not rasterized when using the 
Cairo backend with unicode_demo.py. Haven't looked into that any deeper...
Cheers,
Mike

On 7/5/07, Michael Droettboom <md...@st...> wrote:
> Do you agree that it is still an open question whether it's better to
> spend time improving the matplotib PS backend, or to fix (if possible)
> the issues with matplotlib's Cairo integration? It does ultimately come
> down to a tradeoff: an additional dependency vs. extra maintenance
The postscript backend as it stands is in good shape, and is full
featured (Darren can tell you how much work he has put into supporting
and enhancing the latex support). The last major issue with it is the
font size issue, and with your help a solution is on the horizon. So
it is definitely a good use of time to fix this last bit. It doesn't
sound like your "option 2" is a ton of work, but correct me if I'm
wrong.
While I would love to see cairo become a full featured backend, and
for there to be additional GUI support like tkcairo, wxcairo, etc, we
are a lot farther from that goal than we are to getting the font sizes
down in the existing postscript backend. And I like the fact the mpl
is completely BSD-ish -- relying on a core component which is LGPL
would be a step back in my book, though having it as an option would
be great.
http://www.scipy.org/License_Compatibility
> burden. Maybe it would be a good start to enumerate the Cairo backend's
> current shortcomings.
As a start, you might try adding cairo to the list of backends in
examples/backend_driver.py and see if everything passes, and take a
look at the generated images, eg compared to those of Agg, and see if
you identify any other discrepancies. Steve Chaplin who wrote the
cairo backend can also elaborate.
> (So far I've seen some minor text bugs, and math
> rendering is raster dumps.)
Do you mean mathtext or usetex? - The former is mpl's own math layout
using the cm*.ttf files, and should work like any other text in the
file. The latter uses tex and dvipng rasters (at least in agg), but I
don't think it is supported in cairo. So I am not sure where these
rasters are coming from, unless cairo is converting all text to
rasters.
JDH

Interesting...
When you get a chance, would you mind running the attached script? This 
is how I was finding object leaks before. It takes a single commandline 
argument that is the number of iterations. Can you send me the outputs 
from 1 and 2 iterations? That way we should be able to see what type of 
object is being leaked, which is a good first step.
If that doesn't make it immediately obvious, I'll try this on my Ubuntu 
box at home and see if I can reproduce what you're seeing.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting. I don't get that, but I do get some random segfaults (I 
>> got lucky the first time I tested).
>>
>> I'm awfully surprised that wx.GetApp() would return an iterator, as 
>> you are getting, so maybe it's corruption of some sort?
>>
>> Reverting to revision 3441 on backend_wx.py does resolve this issue 
>> for me, so it is related to removing the wxapp global variable. While I 
>
> [...]
>
> Works for me now, and the result is attached. Object count is still 
> climbing.
>
> Eric
> ------------------------------------------------------------------------
>
> # columns are: iteration, OS memory (k), number of python objects
> #
> 0 18849 75791
> 10 18849 75831
> 20 18849 75871
> 30 18849 75911
> 40 18930 75951
> 50 18930 75991
> 60 19038 76031
> 70 19038 76071
> 80 19038 76111
> 90 19038 76151
> 100 19124 76191
> 110 19124 76231
> 120 19235 76271
> 130 19235 76311
> 140 19316 76351
> 150 19316 76391
> 160 19417 76431
> 170 19417 76471
> 180 19417 76511
> 190 19513 76551
> 200 19513 76591
> 210 19513 76631
> 220 19612 76671
> 230 19612 76711
> 240 19612 76751
> 250 19710 76791
> 260 19710 76831
> 270 19710 76871
> 280 19800 76911
> 290 19800 76951
> 300 19800 76991
> 310 19893 77031
> 320 19893 77071
> 330 19893 77111
> 340 19978 77151
> 350 19978 77191
> 360 20088 77231
> 370 20088 77271
> 380 20088 77311
> 390 20192 77351
> 400 20192 77391
> 410 20192 77431
> 420 20192 77471
> 430 20274 77511
> 440 20274 77551
> 450 20374 77591
> 460 20374 77631
> 470 20374 77671
> 480 20484 77711
> 490 20484 77751
> 500 20484 77791
> 510 20588 77831
> 520 20588 77871
> 530 20588 77911
> 540 20588 77951
> 550 20683 77991
> 560 20683 78031
> 570 20683 78071
> 580 20763 78111
> 590 20796 78151
> 600 20861 78191
> 610 20961 78231
> 620 20961 78271
> 630 20961 78311
> 640 21060 78351
> 650 21060 78391
> 660 21060 78431
> 670 21156 78471
> 680 21156 78511
> 690 21156 78551
> 700 21254 78591
> 710 21254 78631
> 720 21254 78671
> 730 21353 78711
> 740 21353 78751
> 750 21353 78791
> 760 21442 78831
> 770 21442 78871
> 780 21442 78911
> 790 21528 78951
> 800 21528 78991
> 810 21638 79031
> 820 21638 79071
> 830 21638 79111
> 840 21638 79151
> 850 21733 79191
> 860 21733 79231
> 870 21733 79271
> 880 21820 79311
> 890 21820 79351
> 900 21931 79391
> 910 21931 79431
> 920 21931 79471
> 930 21931 79511
> 940 22015 79551
> 950 22015 79591
> 960 22126 79631
> 970 22126 79671
> 980 22126 79711
> 990 22126 79751
> 1000 22207 79791
> 1010 22207 79831
> 1020 22298 79871
> 1030 22298 79911
> 1040 22335 79951
> 1050 22401 79991
> 1060 22503 80031
> 1070 22503 80071
> 1080 22503 80111
> 1090 22601 80151
> 1100 22601 80191
> 1110 22601 80231
> 1120 22699 80271
> 1130 22699 80311
> 1140 22699 80351
> 1150 22798 80391
> 1160 22798 80431
> 1170 22798 80471
> 1180 22897 80511
> 1190 22897 80551
> 1200 22897 80591
> 1210 22995 80631
> 1220 22995 80671
> 1230 22995 80711
> 1240 23086 80751
> 1250 23086 80791
> 1260 23086 80831
> 1270 23180 80871
> 1280 23180 80911
> 1290 23283 80951
> 1300 23283 80991
> 1310 23283 81031
> 1320 23283 81071
> 1330 23366 81111
> 1340 23366 81151
> 1350 23475 81191
> 1360 23475 81231
> 1370 23475 81271
> 1380 23475 81311
> 1390 23552 81351
> 1400 23552 81391
> 1410 23643 81431
> 1420 23643 81471
> 1430 23595 81511
> 1440 23700 81551
> 1450 23808 81591
> 1460 23808 81631
> 1470 23808 81671
> 1480 23787 81711
> 1490 23852 81751
> 1500 23951 81791
> 1510 24048 81831
> 1520 24048 81871
> 1530 24048 81911
> 1540 24146 81951
> 1550 24146 81991
> 1560 24146 82031
> 1570 24247 82071
> 1580 24247 82111
> 1590 24247 82151
> 1600 24344 82191
> 1610 24344 82231
> 1620 24344 82271
> 1630 24442 82311
> 1640 24442 82351
> 1650 24442 82391
> 1660 24542 82431
> 1670 24542 82471
> 1680 24542 82511
> 1690 24639 82551
> 1700 24639 82591
> 1710 24639 82631
> 1720 24738 82671
> 1730 24738 82711
> 1740 24738 82751
> 1750 24837 82791
> 1760 24837 82831
> 1770 24837 82871
> 1780 24935 82911
> 1790 24935 82951
> 1800 24935 82991
> 1810 25025 83031
> 1820 25025 83071
> 1830 25025 83111
> 1840 25118 83151
> 1850 25118 83191
> 1860 25104 83231
> 1870 25170 83271
> 1880 25281 83311
> 1890 25281 83351
> 1900 25281 83391
> 1910 25385 83431
> 1920 25385 83471
> 1930 25385 83511
> 1940 25362 83551
> 1950 25400 83591
> 1960 25469 83631
> 1970 25596 83671
> 1980 25596 83711
> 1990 25693 83751
> 2000 25693 83791
> # columns above are: iteration, OS memory (k), number of python objects
> #
> # uncollectable list: []
> #
> # Backend WX, toolbar toolbar2
> # wxPython version: 2.8.1.1
> # Averaging over loops 1000 to 2000
> # Memory went from 22207k to 25693k
> # Average memory consumed per loop: 3.4860k bytes
>
> 

Michael Droettboom wrote:
> Interesting. I don't get that, but I do get some random segfaults (I 
> got lucky the first time I tested).
> 
> I'm awfully surprised that wx.GetApp() would return an iterator, as you 
> are getting, so maybe it's corruption of some sort?
> 
> Reverting to revision 3441 on backend_wx.py does resolve this issue for 
> me, so it is related to removing the wxapp global variable. While I 
[...]
Works for me now, and the result is attached. Object count is still 
climbing.
Eric

John Hunter wrote:
> On 7/5/07, Michael Droettboom <md...@st...> wrote:
>
>> It may be worthwhile to look at Cairo's font subsetting code if it's
>> determined that the Python Postscript backend has other advantages. I'm
>> sure people who've been here longer than I have can better speak to
>> those pros and cons.
>
> Unfortunately, because it is LGPL, I don't think we can in good
> conscience look at the code, because doing so probably violates the
> spirit of the LGPL which says you can link with it but not reuse the
> code in a non GPL/LGPL program. Others may have a different
> interpretation, and if look but don't copy is OK under the LGPL as it
> is journalism (read and summarize with citation but don't plagiarize)
> then its fine by me but that's not my current understanding.
Agreed. I haven't looked at it the Cairo source yet, so you can still 
consider me "untainted" in that regard. My earlier comment was mainly 
out of licensing confusion. ;)
Do you agree that it is still an open question whether it's better to 
spend time improving the matplotib PS backend, or to fix (if possible) 
the issues with matplotlib's Cairo integration? It does ultimately come 
down to a tradeoff: an additional dependency vs. extra maintenance 
burden. Maybe it would be a good start to enumerate the Cairo backend's 
current shortcomings. (So far I've seen some minor text bugs, and math 
rendering is raster dumps.)
Cheers,
Mike

Interesting. I don't get that, but I do get some random segfaults (I 
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you 
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on backend_wx.py does resolve this issue for 
me, so it is related to removing the wxapp global variable. While I 
like the idea of removing global variables, that was problematic, since 
when the wxapp variable is dereferenced, the whole wx.App is destructed, 
(hence, I believe the segfaults). Since I didn't want to just put the 
wxapp global variable back in, I assigned it to the figure that creates 
it, therefore stick around as long as the figure does. (Is that the 
correct thing for its lifetime?) Anyway, it seems to fix memleak_gui.py 
for me. Ken and Tim will probably want to check that I didn't cause 
more mainloops to start than necessary in the process.
Also, I'm a little puzzled by this code in show() in backend_wx.py:
 wxapp = wx.GetApp()
 if wxapp is not None:
 # wxPython 2.4 has no wx.App.IsMainLoopRunning() method
 imlr = getattr(wxapp, 'IsMainLoopRunning', lambda: False)
 if imlr():
 wxapp.MainLoop()
If I'm reading this correctly, shouldn't it be "if not imlr()"? If it 
is correct, maybe it needs a comment as to why mainloops should be 
started if a mainloop is already running.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> New exception:
>
> efiring@manini:~/programs/py/mpl/tests$ python 
> ../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > 
> ~/temp/memleak_wx_0705.asc
> Traceback (most recent call last):
> File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
> pylab.close(fig)
> File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
> line 742, in close
> _pylab_helpers.Gcf.destroy(manager.num)
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", 
> line 28, in destroy
> figManager.destroy()
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
> line 1405, in destroy
> self.frame.Destroy()
> File 
> "/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
> line 1364, in Destroy
> wxapp.Yield()
> AttributeError: 'listiterator' object has no attribute 'Yield'
>
>
> Eric
>

On 7/5/07, Michael Droettboom <md...@st...> wrote:
> It may be worthwhile to look at Cairo's font subsetting code if it's
> determined that the Python Postscript backend has other advantages. I'm
> sure people who've been here longer than I have can better speak to
> those pros and cons.
Unfortunately, because it is LGPL, I don't think we can in good
conscience look at the code, because doing so probably violates the
spirit of the LGPL which says you can link with it but not reuse the
code in a non GPL/LGPL program. Others may have a different
interpretation, and if look but don't copy is OK under the LGPL as it
is journalism (read and summarize with citation but don't plagiarize)
then its fine by me but that's not my current understanding.
JDH

Mike,
New exception:
efiring@manini:~/programs/py/mpl/tests$ python 
../matplotlib_units/unit/memleak_gui.py -dwx -s1000 -e2000 > 
~/temp/memleak_wx_0705.asc
Traceback (most recent call last):
 File "../matplotlib_units/unit/memleak_gui.py", line 58, in <module>
 pylab.close(fig)
 File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
line 742, in close
 _pylab_helpers.Gcf.destroy(manager.num)
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/_pylab_helpers.py", 
line 28, in destroy
 figManager.destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1405, in destroy
 self.frame.Destroy()
 File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_wx.py", 
line 1364, in Destroy
 wxapp.Yield()
AttributeError: 'listiterator' object has no attribute 'Yield'
Eric

Michael Droettboom wrote:
> Carl Worth wrote:
> 
>> You might take a look at what kind of PostScript and PDF output you
>> get from cairo right now, (since cairo has many different kinds of
>> font subsetting, (type3, type42 and others), and it's regularly being
>> tested on as many PostScript and PDF viewers as possible).
>> 
>> 
> Thanks for the tip. Indeed, using the unicode_test.py example (which 
> probably has a greater than average amount of text in it), the file 
> sizes are (with the size of the font section is parentheses):
>
> backend_ps.py: 135763 (127211)
> cairo: 49102 (39669)
>
> Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 
> 8552)
> 
Though, I should add, there is a bug in Cairo output with 
unicode_demo.py: The y-axis label reads "stream-vera/VeraSe.ttf"...
Cheers,
Mike

Carl Worth wrote:
> You might take a look at what kind of PostScript and PDF output you
> get from cairo right now, (since cairo has many different kinds of
> font subsetting, (type3, type42 and others), and it's regularly being
> tested on as many PostScript and PDF viewers as possible).
> 
Thanks for the tip. Indeed, using the unicode_test.py example (which 
probably has a greater than average amount of text in it), the file 
sizes are (with the size of the font section is parentheses):
 backend_ps.py: 135763 (127211)
 cairo: 49102 (39669)
Interestingly, the non-font part is slightly larger for Cairo (9433 vs. 
8552)
> I don't know if there's anything special about the PostScript output
> you're currently producing that wouldn't make it acceptable to use
> cairo's PostScript output directly. But even if you just want code,
> it's inside cairo under the LGPL.
> 
It may be worthwhile to look at Cairo's font subsetting code if it's 
determined that the Python Postscript backend has other advantages. I'm 
sure people who've been here longer than I have can better speak to 
those pros and cons.
Cheers,
Mike

On 7/5/07, Carl Worth <cw...@cw...> wrote:
> You might take a look at what kind of PostScript and PDF output you
> get from cairo right now, (since cairo has many different kinds of
> font subsetting, (type3, type42 and others), and it's regularly being
> tested on as many PostScript and PDF viewers as possible).
>
> I don't know if there's anything special about the PostScript output
> you're currently producing that wouldn't make it acceptable to use
> cairo's PostScript output directly. But even if you just want code,
> it's inside cairo under the LGPL.
Hey Carl,
I looked at cairo when we first started with the postscript backend,
but in the bad old days it was just a raster dump. I understand it
has come a long way since.
mpl's postscript backend supports latex expressions in PS output,
which requires a fair amount of complex trickery in the postscript
backend, though we we could probably do it with embedded rasters in
cairo. The postscript backend is also standalone with no dependencies
other than mpl and numpy, and adding cairo to the mix might be a bit
difficult for across platforms for some users (though this appears to
have gotten a lot better too). LGPL means we cannot reuse the code.
While I like the idea of using cairo for both raster and vector
outputs in principle because it offloads a lot of work onto a large
and well supported project, it would probably take a fair amount of
work to get all of mpl's functionality into the cairo backend (I don't
know this since I have not tested the backend for some time, but does
it support, for example unicode_demo, mathtext_demo, usetex, and
image_demo ?).
JDH

Yes -- the global wxapp variable was removed (a very good thing). I 
just committed a patch to fix this crash (r3460)
Cheers,
Mike
Christopher Barker wrote:
> Eric Firing wrote:
> 
>> I just updated from svn and tried to rerun the wx test, but ran into an 
>> error:
>>
>> efiring@manini:~/programs/py/mpl/tests$ python 
>> wxapp.Yield()
>> NameError: global name 'wxapp' is not defined
>> 
>
> I think I just saw a note that Ken had committed a patch that a user had 
> provided that kept the wx back-end from re-starting an event loop if 
> there was one already running -- maybe that has something to do with 
> this bug?
>
> -Chris
>
>
>
>
> 

On 2007年7月05日 07:37:21 -1000, Eric Firing wrote:
> > 2. Convert the Truetype font to a Type 3 font (which is basically a set
> > of standard Postscript commands). There is a small C application
> > (http://www.this.net/~frank/ttconv.tar.gz) that converts TTF to Type 3
> > that looks to work quite well. Some modifications would have to be made
> > to actually subset the font and to integrate with Python etc., but it's
> > fairly straightforward code, and the licensing is amenable to including
> > it in the matplotlib source tree.
> >
> > Clearly, I'm leaning toward option #2, but thought I'd open it to the
> > crowd to see if there are any other options or opinions on the matter.
You might take a look at what kind of PostScript and PDF output you
get from cairo right now, (since cairo has many different kinds of
font subsetting, (type3, type42 and others), and it's regularly being
tested on as many PostScript and PDF viewers as possible).
I don't know if there's anything special about the PostScript output
you're currently producing that wouldn't make it acceptable to use
cairo's PostScript output directly. But even if you just want code,
it's inside cairo under the LGPL.
-Carl