[Matplotlib-users] Scale problem with shared axes

2008-07-03 Thread David Trem

Hi,

 While upgrading from matplotlib 0.91.2 to 0.98.2 my software stop 
working properly. I had to adapt one of my function to autoscale visible 
lines. Basically, the modified function seems to work but when I use it 
on a shared axes context I run into problem.


A small script in attachment illustrate the problem.
Actually, the second axes which sharex with first one, prevent the first 
one to be scaled properly. The script works properly with matplotlib 
0.91.2 but fail (autoscaling not working) using 0.98.2
Am I doing something wrong in my autoscale function while updating the 
axs.dataLim ? Or is it something more tricky?


Thanks in advance for your help.

David
import matplotlib

def autoscale_visible_lines(axs):
"""
Function to autoscale only on visible lines.
"""
ignore = True
for line in (axs.lines):
if not line.get_visible():
continue #jump to next line if this one is not visible
if matplotlib.__version__ == '0.98.2':
axs.dataLim.update_from_data_xy(line.get_xydata(),
ignore)
else:
axs.dataLim.update_numerix(line.get_xdata(),
   line.get_ydata(),
   ignore)
ignore = False
axs.autoscale_view()
return None


import pylab as pl

if __name__ == "__main__":

axs1 = pl.subplot(111)
t = pl.arange(0.01, 190.0, 0.01)
s1 = pl.log(t)
l11, = pl.plot(t, s1, 'b-')
l12, = pl.plot(t-50, s1+10)

l11.set_visible(False)
l12.set_visible(True)

twinx = True
if twinx:
axs2 = pl.gcf().add_axes(axs1.get_position(),
 sharex=axs1, frameon=False)
l21, = pl.plot([1], [1], 'r.')

autoscale_visible_lines(axs1)

pl.show()
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] best way to produce many charts

2008-07-03 Thread Florian Mueller
Hi,

John, if I run your script I found following behaviour of distinct
backends in terms of memory leaks:

QtAgg - ok
Agg - ok
GTKAgg - oh, memory leak
PDF - ok, as you mentionend

Hope it helps, seems it is not a problem of matplotlib?!

Cheers,
Florian

P.S:   I use matplotlib svn with following configuration:


BUILDING MATPLOTLIB
matplotlib: 0.98.2
python: 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)  [GCC
4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2)]
  platform: linux2

REQUIRED DEPENDENCIES
 numpy: 1.2.0.dev5283
 freetype2: 9.16.3

OPTIONAL BACKEND DEPENDENCIES
libpng: 1.2.15beta5
   Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
  wxPython: 2.8.4.0
* WxAgg extension not required for wxPython >= 2.8
  Gtk+: gtk+: 2.12.0, glib: 2.14.1, pygtk: 2.12.0,
pygobject: 2.14.0
Qt: Qt: 3.3.7, PyQt: 3.17.3
   Qt4: Qt: 4.3.2, PyQt4: 4.3
 Cairo: 1.4.0

OPTIONAL DATE/TIMEZONE DEPENDENCIES
  datetime: present, version unknown
  dateutil: matplotlib will provide
  pytz: 2007d

OPTIONAL USETEX DEPENDENCIES
dvipng: no
   ghostscript: 8.61
 latex: 3.141592
   pdftops: 3.00

EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.4.0
  enthought.traits: 2.6b1-mpl

[Edit setup.cfg to suppress the above messages]






-- 
--
Florian Mueller
Remote Sensing, Snow & Ice, Meteorology, IT

Innsbruck, Austria
ICQ:
Skype: icephase26

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] best way to produce many charts

2008-07-03 Thread Florian Mueller
> John, if I run your script I found following behaviour of distinct
> backends in terms of memory leaks:
>
> QtAgg - ok
> Agg - ok
> GTKAgg - oh, memory leak
> PDF - ok, as you mentionend
>

Hi John,

I don't understand whats going on, but when I remove the Line
"close(1)" from your script and use "GTKAgg" instead of "PDF" the
memory leak of my previous post is gone!

Cheers,
Florian

-- 
--
Florian Mueller
Remote Sensing, Snow & Ice, Meteorology, IT

Innsbruck, Austria
ICQ:
Skype: icephase26

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] best way to produce many charts

2008-07-03 Thread John Hunter
On Thu, Jul 3, 2008 at 5:23 AM, Florian Mueller <[EMAIL PROTECTED]> wrote:

> I don't understand whats going on, but when I remove the Line
> "close(1)" from your script and use "GTKAgg" instead of "PDF" the
> memory leak of my previous post is gone!

Apparently there is a leak in the creation and destruction of the gtk
pixel buffer.  If you clear it with clf, instead of closing it,
perhaps you aboid this leak.  Just speculating.  But it is good to
know that it doesn't leak with a clf.

JDH

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] findobj in pylab

2008-07-03 Thread John Kitchin
Thanks Matthias. That is a helpful example. 

I have been trying to figure out how to recursively examine all the objects
in fig to see if there is a particular settable property. It seems like the
algorithm has to be recursive so that it goes deep into all the lists, etc.
I have not figured out how to know when you have reached the bottom/end of a
trail.

Such a function would let me set any text property in the whole figure
without needing to know if it was a text object, label, legend, etc... maybe
that is not as valuable as I think it would be though.

j

Message: 2
Date: Wed, 2 Jul 2008 10:00:31 +0200
From: Matthias Michler <[EMAIL PROTECTED]>
Subject: Re: [Matplotlib-users] findobj in pylab
To: matplotlib-users@lists.sourceforge.net
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain;  charset="iso-8859-1"

Hello John,

I'm not sure there is a better way, but the following works for me:

--
from pylab import *

fig = figure()

# adding some subplots / axes instances
subplot(121)
x = linspace(-0.5, 1.5, 10)
plot(x, 0.5*x**2, 'ro', x, 0.33*x**3, 'bs') for i in [2, 4]:
subplot(2,2,i)

# get all axes of the figure 'fig' ...
allaxes = fig.get_axes()
# ... and reset their property x-limits setp(allaxes, 'xlim', (-.5, 1.5))

ax = allaxes[0]
# get all lines of the axes 'ax' ...
lines = ax.get_lines()  # == ax.lines
# ... and reset their markerfacecolor
setp(lines, 'mfc', 'g')

show()

---

best regards
Matthias

On Thursday 26 June 2008 00:21:13 John Kitchin wrote:
> Is there a way to find all the "axes" objects or "line" object handles 
> in pylab? In matlab I used to do something like A = findobj(gcf) 
> Allaxes = findall(a,'Type','axes')
> Set(allaxes,'Fontname','Arial')
>
> Is there a way to do that in pylab/matplotlib?
>
> Thanks,
>
> j
>
>
>
> ---
> John Kitchin
> Assistant Professor
> NETL-IAES Resident Institute Fellow
> Doherty Hall 3112
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> http://kitchingroup.cheme.cmu.edu
>
>


---
John Kitchin
Assistant Professor
NETL-IAES Resident Institute Fellow
Doherty Hall 3112
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
http://kitchingroup.cheme.cmu.edu



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] remove() on text

2008-07-03 Thread John Hunter
On Wed, Jul 2, 2008 at 7:13 PM, Nihat <[EMAIL PROTECTED]> wrote:

> Here are my questions:
> 1. I have extended the Line2D class as I am using _nolegend_ in the label.
> I still wanted to differentiate between lines using something called id.  Is
> there a better way of doing it with built-in attributes?

Nothing built into matplotlib, but python has an "id" function and the
line objects are hashable, so you probably don't need anything else.

> 2. I can remove the line but somehow the text added to the axes does not
> respond to pick events.  Anybody has any thoughts?

It turns out text picking was broken in svn.  When I looked at the
implementation, I saw

try:
l,b,w,h = self.get_window_extent().get_bounds()
except:
# TODO: why does this error occur
#print str(self),"error looking at get_window_extent"
return False,{}

so apparently some developer saw this was broken, hid it with a
blanket except that  was silent, and forgot to get back to the TODO.
bbox.get_bounds did not survive the transform refactor, and is now
called bbox.bounds.  This could of been me, thinking I would fix it
and then forgot about it, but I certainly hope not.  Note to
developers: never catch all exceptions with a blanket except that
doesn't at least warn.  This is fixed in svn so text picking is
working again.

> 3. The neat thing would be to add the text into the CustomLine class so
> line's label is contained in the class.  Not sure how I can do it because
> text needs an axis and axis is nor associated with Line2D until you add the
> line to axis...

> 4. How can I add a constant offset like (2 pixels right, 2 pixels up) at the
> right end of the line for its text label.

This is possible, but is a little harder than it should be because to
do it elegantly you need to override a lot of methods.  If we had a
proper containment API, it would be a lot easier and this is probably
something worth doing.  I wrote up an example (added it to
examples/api/line_with_text.py in svn).

In general, I think it would be nice to add support for all artists
(lines, patches, whatever) to display their label.  We would need to
think a little bit about the API for placing the label (eg if every
artist provides their extent, one could place the label at "upper
right" with a certain offset.

Here is the example:

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.lines as lines
import matplotlib.transforms as mtransforms
import matplotlib.text as mtext


class MyLine(lines.Line2D):

   def __init__(self, *args, **kwargs):
  # we'll update the position when the line data is set
  self.text = mtext.Text(0, 0, '')
  lines.Line2D.__init__(self, *args, **kwargs)

  # we can't access the label attr until *after* the line is
  # inited
  self.text.set_text(self.get_label())

   def set_figure(self, figure):
  self.text.set_figure(figure)
  lines.Line2D.set_figure(self, figure)

   def set_axes(self, axes):
  self.text.set_axes(axes)
  lines.Line2D.set_axes(self, axes)

   def set_transform(self, transform):
  # 2 pixel offset
  texttrans = transform + mtransforms.Affine2D().translate(2, 2)
  self.text.set_transform(texttrans)
  lines.Line2D.set_transform(self, transform)


   def set_data(self, x, y):
  if len(x):
 self.text.set_position((x[-1], y[-1]))

  lines.Line2D.set_data(self, x, y)

   def draw(self, renderer):
  # draw my label at the end of the line with 2 pixel offset
  lines.Line2D.draw(self, renderer)
  self.text.draw(renderer)


fig = plt.figure()
ax = fig.add_subplot(111)
x, y = np.random.rand(2, 20)
line = MyLine(x, y, mfc='red', ms=12, label='line label')
#line.text.set_text('line label')
line.text.set_color('red')
line.text.set_fontsize(16)

ax.add_line(line)


plt.show()

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] findobj in pylab

2008-07-03 Thread John Hunter
On Thu, Jul 3, 2008 at 8:42 AM, John Kitchin <[EMAIL PROTECTED]> wrote:
> Thanks Matthias. That is a helpful example.
>
> I have been trying to figure out how to recursively examine all the objects
> in fig to see if there is a particular settable property. It seems like the
> algorithm has to be recursive so that it goes deep into all the lists, etc.
> I have not figured out how to know when you have reached the bottom/end of a
> trail.
>
> Such a function would let me set any text property in the whole figure
> without needing to know if it was a text object, label, legend, etc... maybe
> that is not as valuable as I think it would be though.

This is a good idea, and I just added an artist method "findobj" in
svn that recursively calls get_children and implements a match
criteria (class instance or callable filter).  There is also a
pyplot/pylab wrapper that operates on current figure by default.  Here
is an example:



import numpy as np
import matplotlib.pyplot as plt
import matplotlib.text as text

a = np.arange(0,3,.02)
b = np.arange(0,3,.02)
c = np.exp(a)
d = c[::-1]

fig = plt.figure()
ax = fig.add_subplot(111)
plt.plot(a,c,'k--',a,d,'k:',a,c+d,'k')
plt.legend(('Model length', 'Data length', 'Total message length'),
   'upper center', shadow=True)
plt.ylim([-1,20])
plt.grid(False)
plt.xlabel('Model complexity --->')
plt.ylabel('Message length --->')
plt.title('Minimum Message Length')

# match on arbitrary function
def myfunc(x):
return hasattr(x, 'set_color')

for o in fig.findobj(myfunc):
o.set_color('blue')

# match on class instances
for o in fig.findobj(text.Text):
o.set_fontstyle('italic')



plt.show()

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] away for a week

2008-07-03 Thread John Hunter
I will be on vacation until July 21st.  I will have sporadic email
contact so I may pop up here and there, but if I have been involved in
a thread and mysteriously disappear, now you know why.

JDH

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] findobj in pylab

2008-07-03 Thread John Kitchin
Cool! That is exactly what I wanted to do!

j

-Original Message-
From: John Hunter [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 03, 2008 10:31 AM
To: John Kitchin
Cc: matplotlib-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [Matplotlib-users] findobj in pylab

On Thu, Jul 3, 2008 at 8:42 AM, John Kitchin <[EMAIL PROTECTED]>
wrote:
> Thanks Matthias. That is a helpful example.
>
> I have been trying to figure out how to recursively examine all the
objects
> in fig to see if there is a particular settable property. It seems like
the
> algorithm has to be recursive so that it goes deep into all the lists,
etc.
> I have not figured out how to know when you have reached the bottom/end of
a
> trail.
>
> Such a function would let me set any text property in the whole figure
> without needing to know if it was a text object, label, legend, etc...
maybe
> that is not as valuable as I think it would be though.

This is a good idea, and I just added an artist method "findobj" in
svn that recursively calls get_children and implements a match
criteria (class instance or callable filter).  There is also a
pyplot/pylab wrapper that operates on current figure by default.  Here
is an example:



import numpy as np
import matplotlib.pyplot as plt
import matplotlib.text as text

a = np.arange(0,3,.02)
b = np.arange(0,3,.02)
c = np.exp(a)
d = c[::-1]

fig = plt.figure()
ax = fig.add_subplot(111)
plt.plot(a,c,'k--',a,d,'k:',a,c+d,'k')
plt.legend(('Model length', 'Data length', 'Total message length'),
   'upper center', shadow=True)
plt.ylim([-1,20])
plt.grid(False)
plt.xlabel('Model complexity --->')
plt.ylabel('Message length --->')
plt.title('Minimum Message Length')

# match on arbitrary function
def myfunc(x):
return hasattr(x, 'set_color')

for o in fig.findobj(myfunc):
o.set_color('blue')

# match on class instances
for o in fig.findobj(text.Text):
o.set_fontstyle('italic')



plt.show()



-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application

2008-07-03 Thread John Hunter
On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark <[EMAIL PROTECTED]> wrote:
> I've written the start of a Cocoa-native backend for matplotlib and
> would like to submit feedback on the code and on the possibility of
> including it in the standard matplotlib distribution. The backend

Hey Barry,

This is great and it is something we are interested in.  I haven't had
a chance to test it and will be away next week but I can give you some
initial thoughts.  In general, we want to pare down the number of
backends but OS X is an important platform and there are certainly
some advantages to doing native rendering.  For us to accept a new
backend, we need to meet the following criteria:

  - someone volunteers to support it.  This is a multi-year
commitment.  Presumably this would be you.

  - feature complete - images, mathtext, rotated text, etc...  It
sounds like the only part you are unsure about is mathtext so perhaps
Michael can advise.  I don't think it will be too hard since Michael
has designed this to work with unicode fonts if requested.

  - gui backends: toolbar support

If you think these are doable, that would be great.  If not, I think
we can rework the backend infrastructure a bit to support external
backend, eg an rc backend setting which points to a file that contains
the backend implementation.  This latter is worth doing in any case,
so if you want to have a look at it

> implementation is not complete (image rendering and mathtext rendering
> are currently no implemented, nor are the print_* methods of the
> FigureCanvas). Image rendering is trivial once I figure out how to get
> the pixel data out of a matplotlib image (I just haven't investigated
> the API yet). The print_* methods are also trivial (see point 1
> below). I'm not sure how to handle mathtext yet. This backend has two
> major feature differences from CocoaAgg:

> 2. The reason I wrote the backend was so that matplotlib could be used
> seemlesslly from within a Cocoa application. Thus this backend *will
> not work* without an existing NSRunLoop. It won't work from the
> terminal or an IPython session. It will work from the in-progress
> Cocoa frontend for IPython or from any other Cocoa application. Again
> there are tradeoffs. On the positive side, figure windows are treated
> like any other application window, selectable from the Window menu
> etc. and matplotlib becomes a seemless part of the application.
> Existing backends designed to create their own runloop (e.g. CocoaAgg
> or TkAgg) cause menubar and run loop problems when used from within an
> existing application. It would be possible to merge the CocoaAgg and
> Cocoa backends in this regard to use the existing run loop if present.

I know nothing about cocoa apps, but from the way you describe this  I
think there may be some confusion in how the backends should work.  I
will speak in terms of gtk since this is the toolkit I know best.  The
FigureCanvas should be a widget which is embeddable in an app (in a
container or window, etc) -- the gtk figure canvas is such a widget
and can be used in a gtk app and mpl knows nothing about the
application or mainloop -- that part is up to the application
developer.  The FigureManager is basically a pylab helper class and is
not meant to be used by the application developer, though I think some
backends may have been designed differently (eg wx).  The
FigureManager creates a canvas, a toolbar and a window, and puts all
the pieces together.  "show" is a pylab construct that raises the
active windows and starts the mainloop.

So your backend *should* be designed so that it can be run from the
shell, basically you need to create an application within the backend
and start the mainloop with show -- this app will only be created in
pylab mode on calls to new_figure_manager and show.  I don't know if
any of this makes sense for cocoa apps, but it is a nice feature for
backends because then those of us who do not know how to build a cocoa
app (and maybe don't want to learn) can still test the backend on
pylab scripts and regular os x users can use your backend w/ pylab
scripts.

JDH

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] turn off antialiasing of text

2008-07-03 Thread fkjt79

Hi

Previously antialiased text can look pretty ugly when converted to bilevel .
Is it possible to turn off antialiasing of text? There seems to be no
setting. I tried using the Wx backend but it antialiased, too.

I am using matplotlib 0.98; tried wxPython 2.6 and 2.8, matplotlib 0.91.4.

I would not mind permanently deactivating antialiasing in text.py or so.

bye,

Felix
-- 
View this message in context: 
http://www.nabble.com/turn-off-antialiasing-of-text-tp18257145p18257145.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] turn off antialiasing of text

2008-07-03 Thread Michael Droettboom
It's certainly not exposed as an option to the user, and I don't think 
there's an easy way to hack this in.  We can tell freetype to give us 
1-bit monochrome bitmaps, but matplotlib currently expects 8-bit 
greyscale, so things don't really work.  It's doable, but it requires 
some non-trivial code changes, and this isn't an oft-requested feature.

One thing you could try is generating a PDF and then converting that 
using a tool that has a no-antialiasing option.  It should produce a 
better result since it's working from the glyph outlines.

There may also be a way to force this in the Cairo backend (which uses 
Cairo for the text rendering).  But I don't know much about Cairo...

Cheers,
Mike

fkjt79 wrote:
> Hi
>
> Previously antialiased text can look pretty ugly when converted to bilevel .
> Is it possible to turn off antialiasing of text? There seems to be no
> setting. I tried using the Wx backend but it antialiased, too.
>
> I am using matplotlib 0.98; tried wxPython 2.6 and 2.8, matplotlib 0.91.4.
>
> I would not mind permanently deactivating antialiasing in text.py or so.
>
> bye,
>
> Felix
>   

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


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


[Matplotlib-users] Python Distribution with matplotlib

2008-07-03 Thread Friedrich Hagedorn
Hello,

today I tried to install mpl in my local home directory at work. This
debian distribution is very old and I had to compile for my own.

But I failed to compile pygtk (special cairo and pango) as a dependency
for mpl. So I have two questions:

1. Does you have an advice to compile mpl with minimal dependencies?

2. Does anybody know a good python dirstibution including mpl?

Thanks,

  Friedrich

-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Python Distribution with matplotlib

2008-07-03 Thread Michael Droettboom
Friedrich Hagedorn wrote:
> Hello,
>
> today I tried to install mpl in my local home directory at work. This
> debian distribution is very old and I had to compile for my own.
>
> But I failed to compile pygtk (special cairo and pango) as a dependency
> for mpl. So I have two questions:
>
> 1. Does you have an advice to compile mpl with minimal dependencies?
>   
You can copy "setup.cfg.template" to "setup.cfg" and then edit the [gui] 
section to disable certain GUIs.  You will need at least one GUI -- 
TkAgg is probably going to be the easiest to get working on an older 
system.  You will need to have Tkinter and the Tcl/Tk development 
headers installed, however.
> 2. Does anybody know a good python dirstibution including mpl?
>   
Enthought has one, but I have no experience with it.

Cheers,
Mike

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


-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users


Re: [Matplotlib-users] Cocoa backend for embedding in Cocoa application

2008-07-03 Thread Barry Wark
On Thu, Jul 3, 2008 at 8:41 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark <[EMAIL PROTECTED]> wrote:
>> I've written the start of a Cocoa-native backend for matplotlib and
>> would like to submit feedback on the code and on the possibility of
>> including it in the standard matplotlib distribution. The backend
>
> Hey Barry,
>
> This is great and it is something we are interested in.  I haven't had
> a chance to test it and will be away next week but I can give you some
> initial thoughts.  In general, we want to pare down the number of
> backends but OS X is an important platform and there are certainly
> some advantages to doing native rendering.  For us to accept a new
> backend, we need to meet the following criteria:
>
>  - someone volunteers to support it.  This is a multi-year
> commitment.  Presumably this would be you.

Yes.

>
>  - feature complete - images, mathtext, rotated text, etc...  It
> sounds like the only part you are unsure about is mathtext so perhaps
> Michael can advise.  I don't think it will be too hard since Michael
> has designed this to work with unicode fonts if requested.

Using unicode fonts should make it easy.

>
>  - gui backends: toolbar support

Currently not implemented, but not a problem.

>
> If you think these are doable, that would be great.  If not, I think
> we can rework the backend infrastructure a bit to support external
> backend, eg an rc backend setting which points to a file that contains
> the backend implementation.  This latter is worth doing in any case,
> so if you want to have a look at it

This would be _very_ useful, whether or not you decide to include a
Cocoa native backend in the distribution. Perhaps also making it
possible to delegate to an other package instead of just a file so
that backends could be installed as separate eggs would be useuful
(e.g. delegate the backend to my.package.backend).

>
>> implementation is not complete (image rendering and mathtext rendering
>> are currently no implemented, nor are the print_* methods of the
>> FigureCanvas). Image rendering is trivial once I figure out how to get
>> the pixel data out of a matplotlib image (I just haven't investigated
>> the API yet). The print_* methods are also trivial (see point 1
>> below). I'm not sure how to handle mathtext yet. This backend has two
>> major feature differences from CocoaAgg:
>
>> 2. The reason I wrote the backend was so that matplotlib could be used
>> seemlesslly from within a Cocoa application. Thus this backend *will
>> not work* without an existing NSRunLoop. It won't work from the
>> terminal or an IPython session. It will work from the in-progress
>> Cocoa frontend for IPython or from any other Cocoa application. Again
>> there are tradeoffs. On the positive side, figure windows are treated
>> like any other application window, selectable from the Window menu
>> etc. and matplotlib becomes a seemless part of the application.
>> Existing backends designed to create their own runloop (e.g. CocoaAgg
>> or TkAgg) cause menubar and run loop problems when used from within an
>> existing application. It would be possible to merge the CocoaAgg and
>> Cocoa backends in this regard to use the existing run loop if present.
>
> I know nothing about cocoa apps, but from the way you describe this  I
> think there may be some confusion in how the backends should work.  I
> will speak in terms of gtk since this is the toolkit I know best.  The
> FigureCanvas should be a widget which is embeddable in an app (in a
> container or window, etc) -- the gtk figure canvas is such a widget
> and can be used in a gtk app and mpl knows nothing about the
> application or mainloop -- that part is up to the application
> developer.  The FigureManager is basically a pylab helper class and is
> not meant to be used by the application developer, though I think some
> backends may have been designed differently (eg wx).  The
> FigureManager creates a canvas, a toolbar and a window, and puts all
> the pieces together.  "show" is a pylab construct that raises the
> active windows and starts the mainloop.

No, in fact you've done a very good job of communicating the
architecture and it appears that it was my mistake in explaining my
work that's led to confusion. backend_cocoa.FigureCanvasView (a
FigureCanvas subclass) is an NSView subclass that can be embedded in a
Cocoa application to render matplotlib figures.

We have a special use case in mind for the
backend_cocoa.FigureManagerCocoa (the FigureManager subclass),
however. I'm not sure if you've been following discussions on the
ipython-dev regarding GUI frontends for IPython, so let me briefly
recap. The new Twisted-based architecture of IPython now allows easy
development of GUI frontends for the IPython engine because the engine
is decoupled from readline. Thus a Cocoa-based frontend for IPython
might behave like a terminal but be implemented as a native Cocoa
widget that can be embedd