matplotlib-users Mailing List for matplotlib

Perfect! Thanks!
Jeff
-----Original Message-----
From: Matt Newville [mailto:new...@ca...] 
Sent: Friday, June 03, 2005 11:47 AM
To: Jeff Peery
Cc: mat...@li...
Subject: Re: [Matplotlib-users] RE: Matplotlib-users digest, Vol 1 #632
- 14 msgs
Jeff,
> Hello, I'm using wx.Agg as a backend for wxpython. I would like to
put
> a plot inside a splitter window. Something that looks like this:
> 
> #adjust figure size
> self.figure = Figure(figsize=(0.5,1), dpi=100)
> 
> #create the canvas
> self.canvas = FigureCanvas(self, -1, self.figure)
> 
> 	 #add canvas to splitter window
>
self.splitterWindow2.SplitVertically(self.window1,self.canvas,4)
> 
> #create a plot instance
> self.axes = self.figure.add_subplot(111)
It's definitely no problem to put a FigureCanvasWxAgg on a 
wx.Window or wx.Panel as in:
class Plotter(wx.Window):
 def __init__(self,parent=None):
 wx.Window.__init__(self,parent,-1)
 self.fig = Figure((5,4), 75)
 self.canvas = FigureCanvasWxAgg(self,-1,self.fig)
 self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76])
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self.canvas,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 
 def plot(self,x,y,*args,**kwds):
 "very simple plot !!"
 self.axes.cla()
 self.axes.plot(x,y,*args,**kwds)
(and wx.Window can be replaced by wx.Panel). A more complete
example is below, though not with a splitter window, it shows
that the Plotter can be placed anywhere. Hope that helps,
--Matt
#!/usr/bin/env python
import wx
import matplotlib.numerix as nx
from matplotlib.figure import Figure
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg
class Plotter(wx.Window):
 def __init__(self,parent=None):
 wx.Window.__init__(self,parent,-1)
 self.fig = Figure((5,4), 75)
 self.canvas = FigureCanvasWxAgg(self,-1,self.fig)
 self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76])
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self.canvas,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 
 def plot(self,x,y,*args,**kwds):
 "very simple plot !!"
 self.axes.cla()
 self.axes.plot(x,y,*args,**kwds)
class PlotFrame(wx.Frame):
 def __init__(self,parent=None):
 wx.Frame.__init__(self,parent,-1,'Frame')
 
 self.plotwin = Plotter(self)
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(wx.StaticText(self, -1 , ' WX Matplotlib example ')
 ,0, wx.LEFT|wx.TOP)
 sizer.Add(self.plotwin,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 def plot(self,x,y,*args,**kwds):
 self.plotwin.plot(x,y,*args,**kwds)
if __name__ == '__main__':
 app = wx.PySimpleApp()
 frame = PlotFrame()
 x = nx.arange(0,10.0,0.05)
 y = nx.sin(x*nx.pi/3)
 frame.plot(x,y,'ro')
 frame.Show()
 app.MainLoop()
#####################

Hi Jeff,
As you are using Boa this might be helpful to you (Matt, no I can't read 
minds but Jeff posted another problem to the Boa list).
I use a splitter to have on the left side some selection criteria and on 
the right side the figure or multiple figures.
You can not directly use matplotlib in the Boa Frame designer, but you 
can do the following.
Anywhere after:
 def __init__(self, parent):
 self._init_ctrls(parent)
I do this:
 self.figure = Figure()
 self.canvas = FigureCanvas(self.splitter, -1, self.figure)
 old = self.splitter.GetWindow2()
 if old == None:
 self.splitter.SplitVertically(self.selectionPanel, 	 
self.canvas, 350)
 else:
 self.splitter.ReplaceWindow(old, self.canvas)
Hope this helps
Werner
Jeff Peery wrote:
> Hello, I'm using wx.Agg as a backend for wxpython. I would like to put
> a plot inside a splitter window. Something that looks like this:
> 
> #adjust figure size
> self.figure = Figure(figsize=(0.5,1), dpi=100)
> 
> #create the canvas
> self.canvas = FigureCanvas(self, -1, self.figure)
> 
> 	 #add canvas to splitter window
> self.splitterWindow2.SplitVertically(self.window1,self.canvas,4)
> 
> #create a plot instance
> self.axes = self.figure.add_subplot(111)
> 
> 
> Alternatively, how would it look if I wanted to add the plot to a
> wx.window? This might be a more simple case... either way I'm not sure
> how to do this? I appreciate the help! Thanks.
> 
> Jeff
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
> a projector? How fast can you ride your desk chair down the office luge track?
> If you want to score the big prize, get to know the little guy. 
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20

>>>>> "N" == N Volbers <mit...@we...> writes:
 N> BTW, is it possible to detect double-clicks?
Not currently -- we could add this to the GUI neutral event handling
mechanism. Probably the easiest way would be to do this at the level
of backend_bases, and check for double clicks ourselves, rather than
trying to wrap double click events for all 5 GUIs.
JDH

>>>>> "N" == N Volbers <mit...@we...> writes:
 N> Hello everyone, I am trying to implement object picking in my
 N> matplotlib-based plotting application. I found two examples.
 N> The 'picker_demo.py' demo is very nice and looks a lot simpler
 N> than the 'object_picker.py' which requires you to use your own
 N> Canvas object. But since object_picker needs to have the
 N> event.inaxes object, it seems impossible to catch any events
 N> outside the axes' bounding box, like 'click on axes title', or
 N> 'click on ticks' or 'click on xlabel'.
Yes, the object_picker demo is very old and deprecated. It is around
from before the days of GUI neutral picking.
I wrote a little demo showing you how to pick the text (title, xlabel,
ylabel, ticklabels). Press "p" over a text instance outside the axes
bounding box and it will turn blue. If you think this is a reasonable
interface, I can make this the basis of a figure pick function. The
question is, what should such a function return. Eg, if you are
outside the axes and click over a text instance, it should return the
text instance. Clear enough. But if you are over an axes and click
on a line, what should it return? The Axes instance, The Line2D
instance, both in a tuple?
from pylab import subplot, title, connect, text, plot, rand, \
 show, gcf, draw
from matplotlib.text import Text
from matplotlib.lines import Line2D
from matplotlib.patches import Patch, Circle
def overtext(t, event):
 'return true if event is over text'
 bbox = t.get_window_extent()
 return bbox.contains(event.x, event.y)
def pick(event):
 
 if event.key!='p': return
 if event.inaxes is not None: # axes pick
 ax = event.inaxes
 a = ax.pick(event.x, event.y)
 
	if isinstance(a, Text):
 a.set_color('r')
 elif isinstance(a, Line2D):
 a.set_markerfacecolor('r')
	elif isinstance(a, Patch):
 a.set_facecolor('r')
 draw()
 else: # figure pick
 fig = gcf()
 texts = []
 for ax in fig.axes:
 texts.extend([ax.xaxis.label, ax.yaxis.label, ax.title])
 texts.extend(ax.xaxis.get_ticklabels())
 texts.extend(ax.yaxis.get_ticklabels()) 
 for t in texts:
 if overtext(t, event):
 t.set_color('blue')
 draw()
 return
 
 
 
connect('key_press_event', pick)
ax = subplot(111)
title('Put mouse over object and press "p" to pick it')
for i in range(20):
 x, y = rand(2)
 text(x,y,'hi!')
for i in range(5):
 x = rand(10)
 y = rand(10)
 plot(x,y,'go')
for i in range(5):
 x = rand()
 y = rand()
 center = x,y
 p = Circle(center, radius=.1)
 ax.add_patch(p)
 
show()

Jeff,
> Hello, I'm using wx.Agg as a backend for wxpython. I would like to put
> a plot inside a splitter window. Something that looks like this:
> 
> #adjust figure size
> self.figure = Figure(figsize=(0.5,1), dpi=100)
> 
> #create the canvas
> self.canvas = FigureCanvas(self, -1, self.figure)
> 
> 	 #add canvas to splitter window
> self.splitterWindow2.SplitVertically(self.window1,self.canvas,4)
> 
> #create a plot instance
> self.axes = self.figure.add_subplot(111)
It's definitely no problem to put a FigureCanvasWxAgg on a 
wx.Window or wx.Panel as in:
class Plotter(wx.Window):
 def __init__(self,parent=None):
 wx.Window.__init__(self,parent,-1)
 self.fig = Figure((5,4), 75)
 self.canvas = FigureCanvasWxAgg(self,-1,self.fig)
 self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76])
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self.canvas,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 
 def plot(self,x,y,*args,**kwds):
 "very simple plot !!"
 self.axes.cla()
 self.axes.plot(x,y,*args,**kwds)
(and wx.Window can be replaced by wx.Panel). A more complete
example is below, though not with a splitter window, it shows
that the Plotter can be placed anywhere. Hope that helps,
--Matt
#!/usr/bin/env python
import wx
import matplotlib.numerix as nx
from matplotlib.figure import Figure
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg
class Plotter(wx.Window):
 def __init__(self,parent=None):
 wx.Window.__init__(self,parent,-1)
 self.fig = Figure((5,4), 75)
 self.canvas = FigureCanvasWxAgg(self,-1,self.fig)
 self.axes = self.fig.add_axes([0.12,0.12,0.76,0.76])
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(self.canvas,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 
 def plot(self,x,y,*args,**kwds):
 "very simple plot !!"
 self.axes.cla()
 self.axes.plot(x,y,*args,**kwds)
class PlotFrame(wx.Frame):
 def __init__(self,parent=None):
 wx.Frame.__init__(self,parent,-1,'Frame')
 
 self.plotwin = Plotter(self)
 sizer = wx.BoxSizer(wx.VERTICAL)
 sizer.Add(wx.StaticText(self, -1 , ' WX Matplotlib example ')
 ,0, wx.LEFT|wx.TOP)
 sizer.Add(self.plotwin,1, wx.LEFT|wx.TOP)
 self.SetSizer(sizer) 
 self.Fit()
 def plot(self,x,y,*args,**kwds):
 self.plotwin.plot(x,y,*args,**kwds)
if __name__ == '__main__':
 app = wx.PySimpleApp()
 frame = PlotFrame()
 x = nx.arange(0,10.0,0.05)
 y = nx.sin(x*nx.pi/3)
 frame.plot(x,y,'ro')
 frame.Show()
 app.MainLoop()
#####################

Hello, I'm using wx.Agg as a backend for wxpython. I would like to put
a plot inside a splitter window. Something that looks like this:
 #adjust figure size
 self.figure = Figure(figsize=(0.5,1), dpi=100)
 
 #create the canvas
 self.canvas = FigureCanvas(self, -1, self.figure)
	 #add canvas to splitter window
 self.splitterWindow2.SplitVertically(self.window1,self.canvas,4)
 
 #create a plot instance
 self.axes = self.figure.add_subplot(111)
Alternatively, how would it look if I wanted to add the plot to a
wx.window? This might be a more simple case... either way I'm not sure
how to do this? I appreciate the help! Thanks.
Jeff

On Friday 03 June 2005 10:46 am, Nicolas Girard wrote:
> On Friday 03 June 2005 16:34, John Hunter wrote:
> > OK, now I am getting the ZeroDivisionError as well. These were caused
> > by recent changes to ticker.py. We'll get it cleared up shortly.
>
> Well, that's a great news ! I had remorses because I didn't have the time
> yet today to upgrade my copy of Numeric and give another try as you advic=
ed
> me yesterday...
I think I was able to fix this. pcolor_demo.py works for me now, and I also=
=20
checked with backend_driver.py. Changes in CVS.=20
Darren

Hi Darren
On Fri, 2005年06月03日 at 09:48 -0400, Darren Dale wrote:
> > Since I also have limited time, I could use epswrite for now. The resulting
> > figures are not fantastic on screen, (I already had smooth line art enabled
> > in Adobe Reader), but marginal improvements can be had by increasing the
> > viewer's resolution. 
> 
> I have some good news! This morning I discovered the ability to set the 
> resolution during the creation of an eps file with epswrite:
> 
> gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=epswrite -dLanguageLevel=3 \ 
> -dEPSFitPage -sOutputFile=foo.eps foo.ps
> 
> This file can be embedded in a new latex document and it has no font 
> information so the text is rendered properly. The final output looks great 
> when printed or viewed with Adobe Reader. I think this is the way to go. As 
> for file size, the eps output from examples/tex_demo.py is about 50KB. 
> 
Hmm, very strange. I'd been getting all the same results without
bothering with the ghostscript resolution switch. I can't honestly see
why the resolution should have much to do with it since I thought it
only affected any vector->raster conversions, whereas epswrite should be
keeping everything as vector, albeit flattened. I am using GNU
Ghostscript 7.07 (2003年05月17日). My files look fine on-screen in ghostview
et al. When converted to PDF they look godawful in xpdf and kpdf but
fine in acroread with "Smooth Line Art" enabled.
 
Cheers
Will
-- 
 Dr William Henney, Centro de Radioastronomía y Astrofísica,
 Universidad Nacional Autónoma de México, Campus Morelia

On Thu, 2005年06月02日 at 22:46 -0400, Darren Dale wrote:
> Since I also have limited time, I could use epswrite for now. The resulting 
> figures are not fantastic on screen, (I already had smooth line art enabled 
> in Adobe Reader), but marginal improvements can be had by increasing the 
> viewer's resolution. The print version is still good. Since epswrite 
> basically converts the fonts to an image anyway, I would like to propose one 
> last time that if text.usetex is true, we draw the text as an image in eps, 
> just until the better solution becomes available. That way the screen version 
> would still look good, the entire picture would open in Adobe illustrator, 
> how big would the files be?
> 
I think this is a good idea, at least to have as an available option. If
you convert the text into an anti-aliased grayscale (or color) image,
then you could probably get away with 150 ppi and the images would not
be large at all (I assume you use something like Flate or RLE
compression). After all, the fraction of the page covered by text will
be small in most instances. It may actually reduce the file size since
you wouldn't need all the font headers.
The only problem I see is that I'm not sure how well PS supports
transparent images - so I can envisage situations in which the text box
might occlude other parts of the graph.
> I am going to add an option to use LaTeX instead of TeX to render the text. 
> TeX is about 30% faster than LaTeX, but ever since John pointed out how much 
> the bitstream fonts suck, I cant help but notice how much the bitstream fonts 
> suck. Right now I am using the pslatex package, and these fonts are quite an 
> improvement. The txfonts package is also nice. How do people feel about two 
> more rc options: one to select tex or latex, and another to choose the font 
> package?
> 
Yes please! I would strongly prefer LaTeX over TeX. Also, I think you
really want a mechanism for the user to specify preamble commands
(loading optional packages, defining macros, etc). This would obviate
the need for a special command to choose the fonts. 
As an aside, I think mathptmx is better than txfonts if you want a Times
Roman math font. The problem with txfonts is that the kernings are
terrible, particularly for superscripts on brackets and the like. On the
other hand, txfonts does have the "varg" option, which replaces the
pointy-bottomed "v", "y" and "g" with round-bottomed versions. The
pointy bottomed "v" is almost indistinguishable from a "nu", which is
rather unfortunate in a formula for the Doppler shift like $\delta v /
c = \delta \nu / \nu$ :)
One final point. I don't understand why you are including ps2epsi in
your toolchain. I thought that the "i" in "epsi" fell by the wayside
over a decade ago. Are there really still any applications out there
that use the %%BeginPreview ... %%EndPreview bitmap? It just seems like
useless and unnecessary bloat to me. It makes tex_demo.eps from the
examples/ directory 5 times larger than it need be!
Best Wishes
Will
> 
-- 
 Dr William Henney, Centro de Radioastronomía y Astrofísica,
 Universidad Nacional Autónoma de México, Campus Morelia

On Friday 03 June 2005 16:34, John Hunter wrote:
> OK, now I am getting the ZeroDivisionError as well. These were caused
> by recent changes to ticker.py. We'll get it cleared up shortly.
>
Well, that's a great news ! I had remorses because I didn't have the time yet 
today to upgrade my copy of Numeric and give another try as you adviced me 
yesterday...
cheers,
nicolas

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:
 >> 
 Nicolas> OK, here you are : I just ran the contour_demo.py from
 Nicolas> the examples directory as follows:
 Nicolas> $ python contour_demo.py --verbose-helpful >&
 Nicolas> contour.log
 Nicolas> You'll find the contour.log file attached to this mail.
 Nicolas> I'm afraid I'll have to leave you, as it's quite late
 Nicolas> here in France...
 Nicolas> Bonne nuit !
OK, now I am getting the ZeroDivisionError as well. These were caused
by recent changes to ticker.py. We'll get it cleared up shortly.
Thanks for letting us know...
JDH

Hi,
there are sometimes I change a little bit the function load to extend it 
a little bit and increase the speed, John didn't like it but that can be 
useful for some other people like you:
http://sourceforge.net/mailarchive/message.php?msg_id=10836085
Regards,
N.
William Henney wrote:
>Hi Chris
>
>On Thu, 2005年06月02日 at 12:28 -0400, Darren Dale wrote:
> 
>
>>>One thing you need to bear in mind if you are using TeX to
>>>generate PS output is that the resultant files will probably be
>>>unacceptable to many scientific journals without further processing. The
>>>production staff generally try to open the PS files in Adobe Illustrator
>>>and this causes multiple problems with files generated both by PyX and
>>>by dvips. 
>>> 
>>>
>>Why is this?
>>
>> 
>>
>
>The main problem was the fonts. The first thing they do as a matter of
>policy is to open the file in Adobe Illustrator. This requires that the
>full font be present in the file apparently (I only have this second
>hand) because Illustrator allows you to edit the text of the labels. A
>little bit like running a PS file through pstoedit and then editing it
>with xfig I guess - that doesn't work with TeX fonts either.
>
>Here is the thread from when I raised the issue with the helpful folk on
>comp.text.tex
>
>http://groups-beta.google.com/group/comp.text.tex/browse_frm/thread/d19575460c561d6b/d447807bb7813dba
>
>There may be a solution that does not involve converting all fonts to
>paths but that was the easiest way out since I was under time-pressure
>and dealing with production staff who seemed to be working from a very
>limited script :) 
>
> 
>
>>>The solution is to convert all fonts to outlines before 
>>>submission (and also make sure all bbox coords are +ve). You can do this
>>>with recent versions of ghostscript:
>>>
>>> gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
>>> -sOutputFile=new.eps old.eps
>>> 
>>>
>>Coincidentally, I was just addressing the use of gs's epswrite this morning on 
>>the matplotlib-devel list. Unfortunately, epswrite will yield a file that 
>>does not render well on screen. Given the increasing popularity of online 
>>publication, it seems this approach for generating eps files would not be 
>>acceptable to scientific journals either.
>>
>> 
>>
>
>I think it looks fine so long as you turn on the "Smooth line art"
>option in your PDF viewer. Unfortunately, this is not on by default in
>acroread, presumably because it increases rendering times. 
>
>If someone can come up with a foolproof way to make figures containing
>TeX fonts that are acceptable to scientific journals, I, for one, would
>be very grateful.
> 
>
> 
>
>>>1. Good, flexible support for reading data from files
>>> 
>>>
>>Could you give an example? In my experience, datafiles tend to get so 
>>complicated that all of Matlabs tools were useless. I end up writing code 
>>specific to every type that isnt as simple as a few comment lines that are 
>>ignored followed by a delimited array of data
>>
>> 
>>
>
>Yes, I wasn't thinking of specialized data formats. Python already has
>fine support for reading, e.g., FITS files. I was thinking more along
>the lines of gnuplot's support for simple ascii data tables. E.g., easy
>selection of columns to plot, single blank line indicating a gap in the
>plot, double blank line indicating a new dataset, etc. This is all
>trivial stuff that I can easily write myself but it would be nice if it
>were a part of the plotting package (PyX does this well). It's not
>really a sticking point though. 
>
>Cheers
>
>Will 
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Yahoo.
>Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
>Search APIs Find out how you can build Yahoo! directly into your own
>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 
>

On Thursday 02 June 2005 10:46 pm, Darren Dale wrote:
> >
> > If someone can come up with a foolproof way to make figures containing
> > TeX fonts that are acceptable to scientific journals, I, for one, would
> > be very grateful.
>
> John has gotten us most of the way there. I think the problem I am having
> embedding these LaTeX-generated eps files is related to the fact that the
> postscript constructs in the image are not isolated from the main documen=
t,
> dvips is not creative in naming them, and therefore the font properties (=
or
> encoding, or something) are being corrupted.
>
> Since I also have limited time, I could use epswrite for now. The resulti=
ng
> figures are not fantastic on screen, (I already had smooth line art enabl=
ed
> in Adobe Reader), but marginal improvements can be had by increasing the
> viewer's resolution.=20
I have some good news! This morning I discovered the ability to set the=20
resolution during the creation of an eps file with epswrite:
gs -dBATCH -dNOPAUSE -dSAFER -q -r6000 -sDEVICE=3Depswrite -dLanguageLevel=
=3D3 \=20
=2DdEPSFitPage -sOutputFile=3Dfoo.eps foo.ps
This file can be embedded in a new latex document and it has no font=20
information so the text is rendered properly. The final output looks great=
=20
when printed or viewed with Adobe Reader. I think this is the way to go. As=
=20
for file size, the eps output from examples/tex_demo.py is about 50KB.=20
Sorry for all the recent noise (this discussion seems to have wandered thro=
ugh=20
several threads), but I was really starting to get worried about meeting my=
=20
deadlines! I'll try to commit the changes today.
Darren

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Why do we have self.set_double_buffered(False)? Its been
 Steve> that way for as long as I can remember, I think John wrote
 Steve> the original code, he may remember the actual reasons.
The original motivation can be found in this thread
 http://www.daa.com.au/pipermail/pygtk/2003-May/005229.html
The basic idea, if I recall correctly, was that since I was already
drawing to a pixmap, I was duplicating some effort by turning on
double buffering. Perhaps this reasoning wasn't correct, since we
were clearly doing something wrong as evidenced by the bug report that
started this discussion.
JDH

John, Jeff,
The attached patch for contour.py includes several minor cleanups plus 
one change of substance--it may require a slight change in some 
invocations of contourf. The change is in the handling of contour 
levels for contourf.
Old version: a list of levels as one of the positional arguments 
specified the lower bound of each filled region; the upper bound of the 
last region was taken as a very large number. Hence, it was not 
possible to specify that z values between 0 and 1, for example, be 
filled, and that values outside that range remain unfilled.
New version: a list of N levels is taken as specifying the boundaries of 
N-1 z ranges. Now the user has more control over what is colored and 
what is not. Repeated calls to contourf (with different colormaps or 
color specifications, for example) can be used to color different ranges 
of z. Values of z outside an expected range are left uncolored.
Example:
Old: contourf(z, [0, 1, 2]) would yield 3 regions: 0-1, 1-2, and >2.
New: it would yield 2 regions: 0-1, 1-2. If the same 3 regions were 
desired, the equivalent list of levels would be [0, 1, 2, 1e38].
Color mapping is still based on the lower limits of the regions.
Eric

On Thu, 2 Jun 2005, William Henney wrote:
> On Wed, 2005年06月01日 at 13:25 -0500, John Hunter wrote:
[...]
> > For *Agg, we use tex + dvipng and load the output as a transparent,
> > anti-aliased raster, caching the dvipng output in ~/.tex.cache for
> > efficiency. For PS, we use tex + dvips + psfrag + latex + a patched
> > ps2epsi. The latter is cumbersome, but it works. In an ideal world,
> > we would simply use tex + dvips but embedding the postscript fragments
> > generated by dvips in arbitrary locations on the figure, but this has
> > proved challenging.
>
> Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
> They have excellent support for tex/latex labels and it seems to be
> implemented in a much "cleaner" way than you describe above. As far as I
> can see, they run a single TeX job containing all the strings from the
> current plot (see the texrunner class in pyx/text.py) and then parse the
> dvi output themselves (see pyx/dvifile.py)
just comment/question, which might be irrelevant, but still:
would a PyX backend make sense?
One approach could be to write out a python
script with the PyX commands corresponding
to the present graphics.
(For example, one then could tweak the resulting script
until the result is fine for publication...)
> The big advantages matplotlib has over PyX in my opinion are a more
> intuitive API and a larger/more-active developer pool and user base.
Creating plots using PyX tends to need more code than with matplotlib.
On the other hand PyX is *very* flexible which is
reflected in its design. OTOH, the quality of PyX generated graphics
exceeds anything else I have looked at in more detail.
Also, it is easily possible to
change the fonts and their size (+ linewidths, colors etc.)
depending on whether one needs a graphics for inclusion
into a publication (e.g. computer modern roman font)
or a presentation (e.g. cmbright family)
so that graphics and the text around it match nicely.
The wish of a "front-end" to PyX did come up on the PyX mailing
list, if I remember correctly.
So maybe using a matplotlib+PyX-backend combination
would be something useful.
Best wishes,
Arnd

Steve, thanks for your long reply. I think I know understand the way it 
works.
Steve Chaplin schrieb:
> [...] 
> expose-events:
> If the window is resized or draw() is called self._draw_pixmap is set to
> True and the whole figure is redrawn to the Pixmap.
> self.window.set_back_pixmap() is then called to set the window
> background to the Pixmap. Then if an expose event occurs, without the
> window being resized or draw() being called, matplotlib does not need to
> do anything. GTK+ handles it for us by automatically filling an exposed
> window with its background, which is our plot.
> 
> This is how it works for GTK+/PyGTK 2.4. However, something changed in
> 2.6 and it no longer always draws the widgets background. I think this
> is a bug, however after rereading the gdk_window_set_back_pixmap()
> manual page I notice it says:
> "The windowing system will normally fill a window with its background
> when the window is obscured then exposed, and when you call
> gdk_window_clear()"
I read that part too, but didn not quite understand it before you 
explained the part about set_back_pixmap().
> What is "normally" supposed to mean? It not something you can rely on,
> so it may just as well be "never". I think that the documentation is
> unclear and opened a documentation bug report
> http://bugzilla.gnome.org/show_bug.cgi?id=306214
> 
> I also found a bug report very similar to the problem experienced in
> matplotlib
> http://bugzilla.gnome.org/show_bug.cgi?id=161561
> its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may
> work OK, and it may just have been a 2.6.0 problem.
Hmmm. The buggy behaviour I noticed was on a machine running pygtk 2.6.1 
and gtk+-2.6.4, so I am not so sure if it was a 2.6.0 problem.
Niklas Volbers.

On Wed, 2005年06月01日 at 05:12 -0700, matplotlib-users-
re...@li... wrote:
> I have started looking at the code and did not quite understand what I 
> found:
> 
> backends/backend_gtk.py has a class FigureCanvasGTK. Its method 
> 'expose_event' is responsible for redrawing.
> In the situation I described, when I leave an opened menu that overlaps 
> the graph, the expose_event is properly called, but the widget is not 
> redrawn. If DBL_BUFFER is set (which it is), the widget is only redrawn, 
> if self._draw_pixmap is set to True. 
Thats not true, see below.
> Of course, this variable is not set 
> to True when GTK closes a menu but only when matplotlib requests a 
> redraw. So, in conclusion, no redraw happens.
> 
> After consulting the PyGTK reference I tried to reactivate double 
> buffering, which is turned of in the backend_gtk.py by the command
> 
> self.set_double_buffered(False)
> 
> I wonder why you set this? Do you want to provide your own double 
> buffering? Why? If you set this value to True, everything will be fine.
> 
> Best regards,
> 
> Niklas Volbers.
Why do we have self.set_double_buffered(False)?
Its been that way for as long as I can remember, I think John wrote the
original code, he may remember the actual reasons.
My guess is because of printing. backend_gtk has two basic functions -
to plot to the display and to plot to a file. If you 
set_double_buffered(False) you can draw to a Pixmap and use the pixmap
to draw to both the screen and to a jpg or png file.
If you draw direct to a gdk.Window you can only save to a file if the
gdk.Window is mapped; if the window is minimised or not yet realized the
print will fail. The 'savefig()' command would not work if called before
'show()'.
expose-events:
If the window is resized or draw() is called self._draw_pixmap is set to
True and the whole figure is redrawn to the Pixmap.
self.window.set_back_pixmap() is then called to set the window
background to the Pixmap. Then if an expose event occurs, without the
window being resized or draw() being called, matplotlib does not need to
do anything. GTK+ handles it for us by automatically filling an exposed
window with its background, which is our plot.
This is how it works for GTK+/PyGTK 2.4. However, something changed in
2.6 and it no longer always draws the widgets background. I think this
is a bug, however after rereading the gdk_window_set_back_pixmap()
manual page I notice it says:
"The windowing system will normally fill a window with its background
when the window is obscured then exposed, and when you call
gdk_window_clear()"
What is "normally" supposed to mean? It not something you can rely on,
so it may just as well be "never". I think that the documentation is
unclear and opened a documentation bug report
http://bugzilla.gnome.org/show_bug.cgi?id=306214
I also found a bug report very similar to the problem experienced in
matplotlib
http://bugzilla.gnome.org/show_bug.cgi?id=161561
its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may
work OK, and it may just have been a 2.6.0 problem.
Regards,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

Hi All,
On Thursday 02 June 2005 6:34 pm, William Henney wrote:
>
> There may be a solution that does not involve converting all fonts to
> paths but that was the easiest way out since I was under time-pressure
> and dealing with production staff who seemed to be working from a very
> limited script :)
>
> > > The solution is to convert all fonts to outlines before
> > > submission (and also make sure all bbox coords are +ve). You can do
> > > this with recent versions of ghostscript:
> > >
> > > gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=3Depswrite -dEPSFitPage \
> > > -sOutputFile=3Dnew.eps old.eps
> >
> > Coincidentally, I was just addressing the use of gs's epswrite this
> > morning on the matplotlib-devel list. Unfortunately, epswrite will yield
> > a file that does not render well on screen. Given the increasing
> > popularity of online publication, it seems this approach for generating
> > eps files would not be acceptable to scientific journals either.
>
> I think it looks fine so long as you turn on the "Smooth line art"
> option in your PDF viewer. Unfortunately, this is not on by default in
> acroread, presumably because it increases rendering times.
>
> If someone can come up with a foolproof way to make figures containing
> TeX fonts that are acceptable to scientific journals, I, for one, would
> be very grateful.
John has gotten us most of the way there. I think the problem I am having=20
embedding these LaTeX-generated eps files is related to the fact that the=20
postscript constructs in the image are not isolated from the main document,=
=20
dvips is not creative in naming them, and therefore the font properties (or=
=20
encoding, or something) are being corrupted.
Since I also have limited time, I could use epswrite for now. The resulting=
=20
figures are not fantastic on screen, (I already had smooth line art enabled=
=20
in Adobe Reader), but marginal improvements can be had by increasing the=20
viewer's resolution. The print version is still good. Since epswrite=20
basically converts the fonts to an image anyway, I would like to propose on=
e=20
last time that if text.usetex is true, we draw the text as an image in eps,=
=20
just until the better solution becomes available. That way the screen versi=
on=20
would still look good, the entire picture would open in Adobe illustrator,=
=20
how big would the files be?
I am going to add an option to use LaTeX instead of TeX to render the text.=
=20
TeX is about 30% faster than LaTeX, but ever since John pointed out how muc=
h=20
the bitstream fonts suck, I cant help but notice how much the bitstream fon=
ts=20
suck. Right now I am using the pslatex package, and these fonts are quite a=
n=20
improvement. The txfonts package is also nice. How do people feel about two=
=20
more rc options: one to select tex or latex, and another to choose the font=
=20
package?

Hi Fernando
On 6/2/05, Fernando Perez <Fer...@co...> wrote:
> scipy's read_array, while not identical to gnuplot's, isn't bad at all:
>=20
Yes, that looks like just what I want. Thanks!
Will
--=20
 Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica,
 Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia