matplotlib-devel Mailing List for matplotlib (Page 475)

I hacked some more on the PDF backend, and now it embeds TrueType
fonts. The positioning is still a bit off, but what looks like a
bigger problem is how to get the /Widths array required by PDF. I've
tried both the width and horiAdvance properties of font.load_char(ch),
and in either case Acrobat Reader tells me the array is invalid. 
Opening the file in Mac OS X's Preview, adding an annotation and then
saving the file changes the array to something acroread does not
complain about (and it also subsets the font). It doesn't look like
it's a simple scaling problem, since the ratio of correct width to
either of my guesses is not constant.

Any ideas?

-- 
Jouni

Hi All,

I have a problem plotting text on a graph that's been rotated using an 
Affine transform. I think I can demonstrate the cause of the problem 
with the following code snippet.

###
from matplotlib.transforms import Affine, Value

a = Affine(Value(1), Value(1), Value(-1), Value(1), Value(0), Value(0))

xy = (123, 456)
print a.inverse_xy_tup(a.xy_tup(xy))
###

Result is not 123, 456 as I expect but -456, 456.

I think the problem is in _transform.cpp. This patch (from HEAD revision 
in SVN) gives the correct result.

1704,1705c1704,1705
<     _ibval = scale*_cval;
<     _icval = -scale*_bval;
---
 >     _ibval = -scale*_bval;
 >     _icval = -scale*_cval;

Thanks,
Alan

On Friday 21 April 2006 14:24, Darren Dale wrote:
> On Friday 21 April 2006 08:35, Ralf Gommers wrote:
> > Hi everyone,
> >
> > I upgraded from version 87.2 to svn (on linux) two days ago, and I
> > noticed that the output to posscript files has changed. The relevant rc
> > settings are:
> >
> > text.usetex         : True
> > ps.papersize      : A4
> > ps.useafm         : True    # use of afm fonts, results in small files
> > ps.usedistiller   : ghostscript
> >
> > The results for a typical picture with both 87.2 and svn are attached.
> > I'm guessing that _svn is the correct behavior since the papersize is A4
> > here, as specified in the rc. But when I use ps2eps the 87.2 version
> > comes out correct and the svn version does not. I tried ps.papersize:
> > auto as well, but then the eps file is only half the graph.
>
> It looks like ghostscript is not calculating the bounding box properly when
> it distills your file. I have done a lot of testing and havent seen this
> problem. Try replacing the bounding box code on line 1179 in backend_ps
> with this:
>
> if ext=='.eps': print >>fh, "%%%%BoundingBox: %d %d %d %d" % bbox
>
> That might help things a little. Note, if your figure runs off the
> postscript page, conversion to eps may result in a clipped image. It's
> better to ask mpl to make an eps file in the first place.
>
> Darren

Thanks for the quick reply Darren.

Generating .eps files has never worked for me, I think I tried this with 0.86 
and 0.87.2 as well. In the script I changed the extension from ps to eps, 
this gives an error. I get the same error with the very simple script:

from scipy import *
from pylab import *

n=100
x=arange(n)
y=rand(n)
figure(1)
clf()
plot(x, y)
savefig('test.eps')
show()


Could replacing the code on line 1179 in backend_ps as you suggested solve 
this?
The traceback of the above script:

exceptions.ValueError                                Traceback (most recent 
call last)

/home/rgommers/data/python/test.py
      8 clf()
      9 plot(x, y)
---> 10 savefig('test.eps')
     11 show()
     12

/usr/lib/python2.3/site-packages/matplotlib/pylab.py in savefig(*args, 
**kwargs)
    800 def savefig(*args, **kwargs):
    801     fig = gcf()
--> 802     return fig.savefig(*args, **kwargs)
    803 if Figure.savefig.__doc__ is not None:
    804     savefig.__doc__ = _shift_string(Figure.savefig.__doc__)

/usr/lib/python2.3/site-packages/matplotlib/figure.py in savefig(self, *args, 
**kwargs)
    656                 kwargs[key] = rcParams['savefig.%s'%key]
    657
--> 658         self.canvas.print_figure(*args, **kwargs)
    659
    660     def colorbar(self, mappable,  cax=None,

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
print_figure(self, outfile, dpi, facecolor, edgecolor, orientation, 
papertype)
    995             # Let's keep the usetex stuff seperate from the generic 
postscript
    996             self._print_figure_tex(outfile, dpi, facecolor, edgecolor,
--> 997                                    orientation, papertype)
    998         else:
    999             if  isinstance(outfile, file):

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
_print_figure_tex(self, outfile, dpi, facecolor, edgecolor, orientation, 
papertype)
   1223
   1224         if rcParams['ps.usedistiller'] == 'ghostscript':
-> 1225             gs_distill(tmpfile, ext=='.eps', ptype=papertype, 
bbox=bbox)
   1226         elif rcParams['ps.usedistiller'] == 'xpdf':
   1227             xpdf_distill(tmpfile, ext=='.eps', ptype=papertype, 
bbox=bbox)

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
gs_distill(tmpfile, eps, ptype, bbox)
   1329     shutil.move(outputfile, tmpfile)
   1330     if eps:
-> 1331         pstoeps(tmpfile, bbox)
   1332
   1333

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
pstoeps(tmpfile, bbox)
   1418     Convert the postscript to encapsulated postscript.
   1419     """
-> 1420     bbox_info = get_bbox(tmpfile, bbox)
   1421
   1422     epsfile = tmpfile + '.eps'

/usr/lib/python2.3/site-packages/matplotlib/backends/backend_ps.py in 
get_bbox(tmpfile, bbox)
   1393 ##    bbox_info = stderr.read()
   1394     verbose.report(bbox_info, 'helpful')
-> 1395     l, b, r, t = [float(i) for i in bbox_info.split()[-4:]]
   1396
   1397     # this is a hack to deal with the fact that ghostscript does not 
return the

ValueError: invalid literal for float(): cidfmap
WARNING: Failure executing file: <test.py>


Cheers,
Ralf

On Friday 21 April 2006 08:35, Ralf Gommers wrote:
> Hi everyone,
>
> I upgraded from version 87.2 to svn (on linux) two days ago, and I noticed
> that the output to posscript files has changed. The relevant rc settings
> are:
>
> text.usetex         : True
> ps.papersize      : A4
> ps.useafm         : True    # use of afm fonts, results in small files
> ps.usedistiller   : ghostscript
>
> The results for a typical picture with both 87.2 and svn are attached. I'm
> guessing that _svn is the correct behavior since the papersize is A4 here,
> as specified in the rc. But when I use ps2eps the 87.2 version comes out
> correct and the svn version does not. I tried ps.papersize: auto as well,
> but then the eps file is only half the graph.

It looks like ghostscript is not calculating the bounding box properly when it 
distills your file. I have done a lot of testing and havent seen this 
problem. Try replacing the bounding box code on line 1179 in backend_ps with 
this:

if ext=='.eps': print >>fh, "%%%%BoundingBox: %d %d %d %d" % bbox

That might help things a little. Note, if your figure runs off the postscript 
page, conversion to eps may result in a clipped image. It's better to ask mpl 
to make an eps file in the first place.

Darren

Hi everyone,

I upgraded from version 87.2 to svn (on linux) two days ago, and I noticed 
that the output to posscript files has changed. The relevant rc settings are:

text.usetex         : True
ps.papersize      : A4 
ps.useafm         : True    # use of afm fonts, results in small files
ps.usedistiller   : ghostscript

The results for a typical picture with both 87.2 and svn are attached. I'm 
guessing that _svn is the correct behavior since the papersize is A4 here, as 
specified in the rc. But when I use ps2eps the 87.2 version comes out correct 
and the svn version does not. I tried ps.papersize: auto as well, but then 
the eps file is only half the graph.

The relevant part of the diff for the produced ps files is:

3,5c3,5
< %%BoundingBox: 30 21 324 252
< %%HiResBoundingBox: 30.768374 21.491999 323.999990 251.999992
< %.....................................
---
> %%BoundingBox: 148 298 442 529
> %%HiResBoundingBox: 148.488370 298.331991 441.719987 528.839984
> %.................................
7c7
< %%CreationDate: 2006/04/19 14:39:16
---
> %%CreationDate: 2006/04/21 12:14:39
63c63
< 360 288 null setpagesize
---
> 595 842 /a4 setpagesize

Is this a bug, or am I doing something wrong?

Thanks,
Ralf

>>>>> "N" == N Volbers <mit...@we...> writes:

    John> I think the easiest solution might be to use nans in the
    John> transform module rather than raise an exception when
    John> transforming an array.  And the clients of the transform, eg
    John> the legend auto-scaling code, can ignore the nans when
    John> deciding where to place the legend.

I just modified the transforms numerix_x_y function to insert nan
instead of raising when the transformation of an element of the
sequence fails

    In [8]: x, y = randn(2,10)

    In [9]: xt, yt = trans.numerix_x_y(x,y)

    In [11]: y
    Out[11]:
    [-0.09215005,-0.08206097, 0.92980313,-0.22293784, 0.83486353,
    0.33593831,
    -1.66880057,-0.1844854 , 0.3235668 ,-0.08853855,]

    In [12]: yt
    Out[12]:
    [        nan,        nan,428.96553625,
    nan,424.47508718,386.52091534,
    nan,        nan,384.95653999,        nan,]

    In [13]: nx.isnan(yt)
    Out[13]: [1,1,0,1,0,0,1,1,0,1,]

Do people think this is the desired behavior?  It will probably make
these functions easier to use by backend writers, who currently have
to fall back on transforming individual elements in try/except blocks

        def drawone(x, y, skip):
            try:
                if skip: raise(ValueError)
                xt, yt = transform.xy_tup((x, y))
                ret = '%g %g %c' % (xt, yt, drawone.state)
            except ValueError:
                drawone.state = 'm'
            else:
                drawone.state = 'l'
                return ret

which is probably a good bit slower.

Should all the transform methods have these symantics (nan on fail
rather than raise) or should the methods that transform single points
raise and the methods that transform sequences insert nans when
individual points fail?

I used the std c++ numeric_limits quiet_NaN

  http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html#std_1_1numeric__limitse5

which worked with the MPL_isnan test from numerix on linux with
Numeric, numarray and numpy.  It would probably be worth testing on
other platforms

  from pylab import subplot, nx  
  ax = subplot(111)
  ax.semilogy(nx.arange(10), nx.mlab.rand(10)) 
  trans = ax.transData
  x,y = nx.mlab.randn(2,10)
  xt,yt = trans.numerix_x_y(x,y)
  print yt
  print nx.isnan(yt)

JDH

>>>>> "N" == N Volbers <mit...@we...> writes:

    N> I guess this can be considered a bug, or not?

Yes, it's a bug.  We try to handle invalid transformations w/o
failing.

I think the easiest solution might be to use nans in the transform
module rather than raise an exception when transforming an array.  And
the clients of the transform, eg the legend auto-scaling code, can
ignore the nans when deciding where to place the legend.

JDH

Hello Steven,

Steven Chaplin wrote:

>On Wed, 2006-04-19 at 17:47 +0200, N. Volbers wrote:
>  
>
>>Consider the following settings for the Axes ax:
>>
>>ax.set_yscale('log')
>>ax.set_ylim(min=-5)
>>
>>and then redraw the axes. The negative minimum value raised an exception 
>>in my case:
>>    
>>
>
>I think it should be "ax.set_ylim(ymin=-5)".
>set_ylim() already catches this type of error.
>
>#!/usr/bin/env python
>from pylab import *
>x = arange(0.0, 20.0, 0.01)
>y = x - 10
>semilogy(x, y)
>ylabel('semilogy')
>grid(True)
>ylim(ymin=-5)
>show()
>
>Running the above script gives:
>  File "./logtest.py", line 8, in ?
>    ylim(ymin=-5)
>  File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
>1131, in ylim
>    ret = ax.set_ylim(*args, **kwargs)
>  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1314,
>in set_ylim
>    raise ValueError('Cannot set nonpositive limits with log transform')
>ValueError: Cannot set nonpositive limits with log transform
>
>  
>
Yes, you are absolutely right.

Somehow I did not really understand my problem at all, but now I do!

The problem was not at all the limits. Some of my sample data contained 
a negative value, and the error message in my previous posting was 
simply saying, that you can't apply the logarithmic transformation to 
this data point. Now, whenever this happens, my error dialog appears, 
which triggers the expose event for the canvas, which again will raise 
the ValueError! There it is, my infinity loop.

But of course it is not that easy! You had negative values as well in 
your example, and nothing happened! This was because you had no legend 
that was autopositioned. Try this and see how it fails:

#!/usr/bin/env python
from pylab import *
x = arange(0.0, 20.0, 0.01)
y = x - 10
ylabel('semilogy')
grid(True)
ylim(ymin=-5)
semilogy(x, y)
legend(loc='best')
show()

I guess this can be considered a bug, or not?

Best regards,

Niklas.

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
    >> 
    Jordan> No, as I said before, matplotlib 0.72 does the same thing,
    Jordan> and I have installed and run matplotlib-0.72 under cygwin
    Jordan> before, so I assume this means that cygwin is at fault
    Jordan> somehow.  I'm just trying to see if I can find where it is
    Jordan> at fault so I have something specific to pester the cygwin
    Jordan> devs about.

    Jordan> Jordan

Oh, I misunderstood this.  Have you tried building other C extension
modules before?  How about C++ extension modules?  You might try and
create a minimal SWIG C++ example and see if you can build that, and if
not you could submit that as a bug to the SWIG/cygwin devs.  What is
your gcc version?  Can you upgrade gcc or are you using the latest?

I use the mingw environment under win32, but not cygwin.  That way you
can use gcc and gnu tools, but native win32 python and binaries.  Much
easer, IMO.

JDH

On Wed, 2006-04-19 at 17:47 +0200, N. Volbers wrote:
> Consider the following settings for the Axes ax:
> 
> ax.set_yscale('log')
> ax.set_ylim(min=-5)
> 
> and then redraw the axes. The negative minimum value raised an exception 
> in my case:

I think it should be "ax.set_ylim(ymin=-5)".
set_ylim() already catches this type of error.

#!/usr/bin/env python
from pylab import *
x = arange(0.0, 20.0, 0.01)
y = x - 10
semilogy(x, y)
ylabel('semilogy')
grid(True)
ylim(ymin=-5)
show()

Running the above script gives:
  File "./logtest.py", line 8, in ?
    ylim(ymin=-5)
  File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line
1131, in ylim
    ret = ax.set_ylim(*args, **kwargs)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1314,
in set_ylim
    raise ValueError('Cannot set nonpositive limits with log transform')
ValueError: Cannot set nonpositive limits with log transform


Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

> The VERBOSE flags generate runtime, not compile time information, so
> try reimporting a module that fails and see if you get any extra
> info.  Eg matplotlib.backends._backend_agg
>
> Also, please confirm that matplotlib._agg also dumps.
>   
Oh!  Ok, yeah, they all still dump, including matplotlib._agg, and the 
verbose compile doesn't seem to add any new info.
> I find it odd that an extension built with SWIG, and one built with
> PYCXX, have the same behavior, since their is almost no overlap in
> these tools.  It suggests something may be wrong with your setup
> rather than matplotlib.  In your current environment, can you still
> build and run an older mpl?
>   
No, as I said before, matplotlib 0.72 does the same thing, and I have 
installed and run matplotlib-0.72 under cygwin before, so I assume this 
means that cygwin is at fault somehow.  I'm just trying to see if I can 
find where it is at fault so I have something specific to pester the 
cygwin devs about.

Jordan

>
> First thing to try is simply rm -rf the site-packages/matplotlib and
> build subdirs and get a clean install.  Installing a new version over
> a pretty old version has been known to cause trouble, segfault, etc.
>   
I always wipe the install and build directories before installing a new 
version.
> Try importing these packages individually
>
>   import matplotlib._image
>   import matplotlib._transforms
>
>   #one of these three depending on which numerix package you are using
>   import matplotlib.backends._na_backend_agg # for numarray
>   import matplotlib.backends._nc_backend_agg # for Numeric
>   import matplotlib.backends._ns_backend_agg # for numpy
>
>   import matplotlib.backends._tkagg
>   import matplotlib._agg
>   
All of them simply dump to the command line (though I only tried 
Numeric, not numpy or numarray).
> If that shed additional light, again flush the build and install dirs,
> and try setting VERBOSE=True in setup.py before doing a clean install.
> The VERBOSE setting will generate lots of extra output and may help
> indicate where the segfault is occurring   
Hmm.  There are a bunch of warnings that one might be using variables 
uninitialized (which I'm ignoring as compiler whining), and a series of 
warning like this:

./CXX/Extensions.hxx: In constructor 
`Py::PythonExtension<T>::PythonExtension() [with T = LazyValue]':
src/_transforms.h:57:   instantiated from here
./CXX/Extensions.hxx:477: warning: right-hand operand of comma has no 
effect

I suspect these are harmless as well, but I don't really know c++ so I 
can't tell what it's complaining about.

Jordan

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:

    Jordan> I've tried this with Numeric 24.2, Numeric 24.0, numpy
    Jordan> 0.9.6, matplotlib svn, matplotlib-0.86, and
    Jordan> matplotlib-0.74; all give the same result.  I believe this
    Jordan> is a problem with cygwin, because a year or so ago I
    Jordan> installed matplotlib-0.74 with Numeric-24.0 and it worked
    Jordan> fine.  Note that "import matplotlib" appears to work, but
    Jordan> "import matplotlib.pylab" does not.  Any idea what's going
    Jordan> wrong, or suggestions about where to start hacking?

First thing to try is simply rm -rf the site-packages/matplotlib and
build subdirs and get a clean install.  Installing a new version over
a pretty old version has been known to cause trouble, segfault, etc.

Try importing these packages individually

  import matplotlib._image
  import matplotlib._transforms

  #one of these three depending on which numerix package you are using
  import matplotlib.backends._na_backend_agg # for numarray
  import matplotlib.backends._nc_backend_agg # for Numeric
  import matplotlib.backends._ns_backend_agg # for numpy

  import matplotlib.backends._tkagg
  import matplotlib._agg


If the last two work and the others don't, it is likely you need to
upgrade your gcc, because on some platforms (OS X for sure) old
versions of gcc cannot compile new versions of pycxx, which matplotlib
uses for building some but not all of it's extensions.  Report back
which if any work or segfault or raise tracebacks,

If that shed additional light, again flush the build and install dirs,
and try setting VERBOSE=True in setup.py before doing a clean install.
The VERBOSE setting will generate lots of extra output and may help
indicate where the segfault is occurring 

JDH

PS I just added these instructions to svn in a file called SEGFAULTS.
We should add tricks and trips for diagnosing segfaults here.

Does anyone have any idea why matplotlib now crashes python under 
cygwin?  Here's what I did:

1. Install cygwin, including gcc, python, and the libpng and libfreetype 
development packages.
2. Install Numeric 24.2 from tar.gz file.  This works fine.
3. Install matplotlib from svn.  This works fine.
4. Execute "from pylab import *" inside python.  Instant dump to the 
bash shell without error message.  Setting verbose=debug-annoying 
doesn't add any information.

Let's show the whole thing in gory detail, shall we?
-----------------------------
freedryk@jlaptop ~
$ python
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from pylab import *
loaded rc file /cygdrive/d/freedryk/.matplotlib/matplotlibrc
matplotlib version 0.88
verbose.level debug-annoying
interactive is False
platform is cygwin
loaded modules: ['pylab', '_bisect', '__future__', 'copy_reg', 
'sre_compile', 'd
istutils', 'itertools', '_sre', '__main__', 'site', '__builtin__', 
'datetime', '
matplotlib.re', 'matplotlib.tempfile', 'encodings', 'pytz.datetime', 
'shutil', '
distutils.string', 'dateutil', 'matplotlib.datetime', 'posixpath', 
'_random', 't
empfile', 'errno', 'matplotlib.warnings', 'binascii', 
'encodings.codecs', 'sre_c
onstants', 're', 'matplotlib.md5', 'os.path', 'pytz.sys', '_codecs', 
'distutils.
sysconfig', 'encodings.exceptions', 'pytz.sets', 'math', 'fcntl', 
'stat', 'zipim
port', 'string', 'warnings', 'encodings.types', 'UserDict', 
'encodings.ascii', '
matplotlib.sys', 'matplotlib', 'distutils.os', 'sys', 'pytz.tzinfo', 
'pytz', 'ma
tplotlib.__future__', 'codecs', 'distutils.re', 'readline', 
'matplotlib.pytz', '
types', 'md5', 'matplotlib.dateutil', 'matplotlib.os', 'thread', 'sre', 
'bisect'
, 'matplotlib.distutils', 'signal', 'distutils.errors', 'random', 
'linecache', '
matplotlib.shutil', 'posix', 'encodings.aliases', 'sets', 'exceptions', 
'sre_par
se', 'pytz.bisect', 'distutils.sys', 'os', 'strop']
numerix Numeric 24.2

freedryk@jlaptop ~
$
--------------------------------

I've tried this with Numeric 24.2, Numeric 24.0, numpy 0.9.6, matplotlib 
svn, matplotlib-0.86, and matplotlib-0.74; all give the same result.  I 
believe this is a problem with cygwin, because a year or so ago I 
installed matplotlib-0.74 with Numeric-24.0 and it worked fine.  Note 
that "import matplotlib" appears to work, but "import matplotlib.pylab" 
does not.  Any idea what's going wrong, or suggestions about where to 
start hacking?

Jordan Dawe

On 4/19/06, Ken McIvor <mc...@ii...> wrote:
> On 04/19/06 11:09, Charlie Moad wrote:
> > Hmm, not sure.  I will try this when I get home.
>
> If the first patch doesn't work, this one might.  It basically does VC++6=
's
> job for it by expanding the member function templates into polymorphic me=
mber
> functions that call an external function template with a bunch of extra
> arguments (theRenderer and friends).
>
> It costs in terms of flexibility and is an ugly solution but is probably
> preferable to dropping the templates entirely.
>

I just sent the errors for the last 2 patches you posted.  It really
isn't worth all this time and effort, Ken.  I do appreciate the hard
work though.

- Charlie

I have had errors complaining about uint and ushort being defined in  
both types.h and numpy/arrayobject.h.  I fixed this problem by  
commenting out the lines in arrayobject where these things were  
redefined -- matplotlib compiles fine then.  This hack is unnecessary  
on the PPC Mac (as well as other platforms, I imagine).

Will this hack give me trouble with other packages?  Do any of you  
have suggestions for a more permanent fix?

-Rob

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

On 04/19/06 11:09, Charlie Moad wrote:
> Hmm, not sure.  I will try this when I get home.

If the first patch doesn't work, this one might.  It basically does VC++6's 
job for it by expanding the member function templates into polymorphic member 
functions that call an external function template with a bunch of extra 
arguments (theRenderer and friends).

It costs in terms of flexibility and is an ugly solution but is probably 
preferable to dropping the templates entirely.

Ken

Steven,

thanks for your reply to my rather confusing email.


Steven Chaplin wrote:

>On Tue, 2006-04-18 at 20:11 -0700,
>mat...@li... wrote:
>
>>        [...]       
>>        
>>        So what I would like to propose is a modification of
>>        expose_event 
>>        located in backends/backend_gtk.py to better handle any
>>        exceptions that 
>>        it might trigger.
>>        One not so nice solution of mine was to wrap the method in a 
>>        try...finally statement, which ensures that False is returned
>>        and the 
>>        expose_event is stopped:
>>        
>>        
>>            def expose_event(self, widget, event):
>>                """Expose_event for all GTK backends. Should not be
>>        overridden.
>>                """
>>                if _debug: print 'FigureCanvasGTK.%s' % fn_name()
>>        
>>            try:
>>                if GTK_WIDGET_DRAWABLE(self):
>>                if self._need_redraw:
>>                    x, y, w, h = self.allocation
>>                    self._pixmap_prepare (w, h)
>>                    self._render_figure(self._pixmap, w, h)
>>                    self._need_redraw = False
>>        
>>                x, y, w, h = event.area
>>                self.window.draw_drawable
>>        (self.style.fg_gc[self.state],
>>                               self._pixmap, x, y, x, y, w, h)
>>            finally:
>>                return False  # finish event propagation?
>>        
>>        
>>        Of course, this has the obvious disadvantage, that no
>>        exception is 
>>        triggered at all, which is undesirable.
>>
>I don't understand, the exception is still raised after the 'finally'
>clause.
>
>
Yes, you are right, it _should_ be triggered. However, I have now 
realized that expose_event wasn't the problem at all in my situation:

Consider the following settings for the Axes ax:

ax.set_yscale('log')
ax.set_ylim(min=-5)

and then redraw the axes. The negative minimum value raised an exception 
in my case:

Traceback (most recent call last):
  File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 294, in expose_event
    self._render_figure(self._pixmap, w, h)
  File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 282, in _render_figure
    self.figure.draw (self._renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line 
529, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1469, 
in draw
    self.legend_.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
208, in draw
    self._update_positions(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
574, in _update_positions
    ox, oy = self._find_best_position(w, h)
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
444, in _find_best_position
    verts, bboxes, lines = self._auto_legend_data()
  File "/usr/lib/python2.4/site-packages/matplotlib/legend.py", line 
340, in _auto_legend_data
    xt, yt = trans.numerix_x_y(xdata, ydata)
ValueError: Domain error on Transformation::numerix_x_y

So somehow the _auto_legend_data method would fail in handling the 
negative limit (which of course should not have been there).
This caused my error box to pop up, which would yet again trigger 
another expose_event, which of course would again cause the same 
exception again! My try...finally statement omitted this _somehow_, even 
though I agree with you that the exception should have been triggered 
anyway.

>
>You could simply popup the user-friendly dialog and then kill the
>program after the user has read the message and clicked "OK".
>
No way!

>
>When you use semilogy(), matplotlib ignores the values <= 0 (I'm not
>sure where the code is that does that), I think an application should do
>the same.
>
>If we add try ... finally to expose_event() that would mean we are
>handling application errors within library code, which I don't think is
>right. Also, this problem would affect all backends so it would probably
>be better to handle it (if it is needed) in the Figure.draw() rather
>than having to modify every backend.
>
Basically there are three options:

(1) Leave everything as it is and let matplotlib blame the user/library 
user if he/she set a negative limit for a logarithmic plot.

(2) Catch the ValueError in _auto_legend_data and continue graciously. 
Is there any way to output friendly informative warnings? I did
the following in _auto_legend_data in legend.py:

            if isinstance(handle, Line2D):

                try:
                    xdata = handle.get_xdata(valid_only = True)
                    ydata = handle.get_ydata(valid_only = True)
                    trans = handle.get_transform()
                    xt, yt = trans.numerix_x_y(xdata, ydata)
                except ValueError:
                    pass # maybe output an error message here?
                else:
                    # XXX need a special method in transform to do a 
list of ve$                    averts = [inv(v) for v in zip(xt, yt)]
                    lines.append(averts)

(3) Omit the ValueError: Use 'None' as limit, if we have a logarithmic 
plot and a negative limit. Output a hint. Unfortunately I am too 
unfamiliar with matplotlib to decide where this check should be done.


Best regards,

Niklas Volbers.

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> Hi, I am trying to add a pdf compression level parameter to
    Jouni> the rc file, with possible values 0 (no compression) or 1
    Jouni> to 9 (as in gzip). If I make the default nonzero but set
    Jouni> the value to 0 in my rc file, the default takes over. It
    Jouni> seems to me that the two "if cval" tests in rc_params
    Jouni> should be changed to "if cval is not None"; but would this
    Jouni> have unintended consequences?

I took a quick look, and 'if cval is not None' looks right to me too.

JDH

Charlie,

I've been thinking about ways to preserve the templated-ness of RendererAgg's 
_fill_and_stroke() and _render_lines_path() while placating the VC++6 gods. 
Looking at the situation from a relatively fresh perspective, it seems that 
the simplest solution is to inline the definitions of those member function 
templates inside the class.  However, I cannot for the life of me rember if 
you/I/we already tried this.  Sourceforge's website is down right now and I 
don't have my laptop handy, so I cannot check the archive of matplotlib-devel.

Attached is a patch that inlines the aformentioned methods.  If this is a 
known dead-end and I've forgotten that then please disregard it.  Otherwise, 
please let me know if it does the trick.  I'm going to start working on a more 
complicated and less general solution now.

Ken

Hi,

I am trying to add a pdf compression level parameter to the rc file,
with possible values 0 (no compression) or 1 to 9 (as in gzip). If I
make the default nonzero but set the value to 0 in my rc file, the
default takes over. It seems to me that the two "if cval" tests in
rc_params should be changed to "if cval is not None"; but would this
have unintended consequences?

-- 
Jouni

On Tue, 2006-04-18 at 20:11 -0700,
mat...@li... wrote:
>         Hello everyone,
>         
>         I have the following problem with my application, which allows
>         you to 
>         manipulate some of properties of a plot through the use of a
>         gui-style 
>         property editor:
>         
>         Whenever I set the y-axis scale to logarithmic, but have the y
>         range 
>         include a negative value, I will get a ValueError upon
>         expose_event. The 
>         bad thing is now, that my application catches all exceptions
>         and 
>         displays a user-friendly dialog, explaining or listing the
>         exception and 
>         offering the user to mail the output to the dumb author of the
>         program. 
>         But whenever the user quits the dialog, a new expose event of
>         the canvas 
>         will be triggered, leading to an unstoppable series of
>         exceptions 
>         (except when using xkill of course).
>         
>         So what I would like to propose is a modification of
>         expose_event 
>         located in backends/backend_gtk.py to better handle any
>         exceptions that 
>         it might trigger.
>         One not so nice solution of mine was to wrap the method in a 
>         try...finally statement, which ensures that False is returned
>         and the 
>         expose_event is stopped:
>         
>         
>             def expose_event(self, widget, event):
>                 """Expose_event for all GTK backends. Should not be
>         overridden.
>                 """
>                 if _debug: print 'FigureCanvasGTK.%s' % fn_name()
>         
>             try:
>                 if GTK_WIDGET_DRAWABLE(self):
>                 if self._need_redraw:
>                     x, y, w, h = self.allocation
>                     self._pixmap_prepare (w, h)
>                     self._render_figure(self._pixmap, w, h)
>                     self._need_redraw = False
>         
>                 x, y, w, h = event.area
>                 self.window.draw_drawable
>         (self.style.fg_gc[self.state],
>                                self._pixmap, x, y, x, y, w, h)
>             finally:
>                 return False  # finish event propagation?
>         
>         
>         Of course, this has the obvious disadvantage, that no
>         exception is 
>         triggered at all, which is undesirable.
I don't understand, the exception is still raised after the 'finally'
clause.

>         Are there any better approaches to this?
>         
>         Best regards,
>         
>         Niklas Volbers.

You could simply popup the user-friendly dialog and then kill the
program after the user has read the message and clicked "OK".

When you use semilogy(), matplotlib ignores the values <= 0 (I'm not
sure where the code is that does that), I think an application should do
the same.

If we add try ... finally to expose_event() that would mean we are
handling application errors within library code, which I don't think is
right. Also, this problem would affect all backends so it would probably
be better to handle it (if it is needed) in the Figure.draw() rather
than having to modify every backend.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Jouni" == Jouni K Seppanen <jk...@ik...> writes:

    Jouni> Hello, I'm attaching the beginnings of a PDF backend. It
    Jouni> doesn't implement much of the backend protocol yet, but
    Jouni> enough for this script to produce the attached output:

Very nice!  I committed this to svn.  If you would like to work on it
there, send me a sourceforge id and I'll add you to the committers
list.  


JDH

On Wednesday 19 April 2006 1:31 am, Jouni K Seppanen wrote:
> Hello,
>
> I'm attaching the beginnings of a PDF backend. It doesn't implement
> much of the backend protocol yet, but enough for this script to
> produce the attached output:
>
>   import matplotlib
>   matplotlib.use('Pdf')
>   from pylab import *
>   x = arange(0, 10, 0.05)
>   plot(x, sin(x), 'b-', lw=10, alpha=0.8)
>   plot(x, cos(x), 'r-', lw=10, alpha=0.8)
>   plot(x, cos(x+1), 'g-', lw=10, alpha=0.8)
>   savefig('foo.pdf')


Nice work, Jouni.

Hello,

I'm attaching the beginnings of a PDF backend. It doesn't implement
much of the backend protocol yet, but enough for this script to
produce the attached output:

  import matplotlib
  matplotlib.use('Pdf')
  from pylab import *
  x = arange(0, 10, 0.05)
  plot(x, sin(x), 'b-', lw=10, alpha=0.8)
  plot(x, cos(x), 'r-', lw=10, alpha=0.8)
  plot(x, cos(x+1), 'g-', lw=10, alpha=0.8)
  savefig('foo.pdf')

-- 
Jouni