matplotlib-devel Mailing List for matplotlib

Hi,

Anyone is welcome to work on the SVG backend.  I didn't realize that
John thought I was hard at work on improving it, when actually I've been
happily using it.  Sorry for not communicating that... I'm not going to
have any time to work on it in the near future, so go nuts.  I'm an
amateur, so there are plenty of bugs!  :)

On Thu, 2004-07-08 at 16:16, John Hunter wrote:

> There is an SVG backend already in matplotlib.  It hasn't been
> announced because it is in development by Jared Wahlstrand.  Perhaps
> Jared can give a status report on what needs to be done, and you might
> want to help out.  He might have a more recent copy in his development
> tree than I do.
> 
> Here are the issues as I understand them:
> 
>   * image support

This is waiting on a save_image function in the Agg backend, so that we
can link to an external PNG file.

>   * font support (freetype vs afm), use of font families /
>     font_manager

Is this the issue of 'helvetica' versus 'sans serif'?

>   * mathtext

I don't know where to begin here, but the implementation is going to
look a lot like the PS backend.  It would be cool to embed MathML, but
good luck finding a viewer capable of reading it... :)

>   * some oddness when the user calls savefig with a high dpi?
>     Shouldn't SVG ignore the dpi setting?  That's what I did in
>     backend_ps.

You're right, it shouldn't need to know the dpi.  This is an artifact
from when I ported everything from the PS backend.

>   * There also appears to be some problem in centering the figure?

I haven't experienced this.

I've been using it to export to inkscape to make figures for papers and
conference talks and haven't had any major problems.  The code in 0.60
is the same as I've been using, with the exception of adding another
case to print_figure() to switch to the SVG backend when the filename
has a .svg extension.

It's not complicated code, so it should be easy to understand, but let
me know if you have any questions.

Cheers,

Jared

Typo:

->to the fig.legend placement. I had to problem placing the axes.

should have read: I had _no_ problem placing the axes

sorry,

Jim

Hi,

  As you know in matplotlib 0.60 fig.legend does allow
placing the legend outside of the axis. I'm hoping to find its
position, and then position the axes where i want wrt
to the fig.legend placement. I had to problem placing the axes.
For the legend i tried
rec = legendInstance.get_frame()
lVertices = rec.get_verts()  

I think that the lVertices don't truly represent where the
legend actually gets placed. e.g. putting the legend at the upper left
or lower right don't change the values in lVertices.

I guess what i'm really trying to accomplish is a legend placement
along the lines of something like 

'outside upper left' --> meaning outside of the axes to the upper left
'outside lower left' --> meaning outside of the axes to the lower left   
etc.

I think i can do this at my application level...if i can either get the
legend placement, or set the position.  Another approach would be
to attempt to hack up the legend.py code to accept other placements.

Am i making this way more complicated than it is?
Any suggestions?

Thanks,

Jim

Quoting John Hunter <jdh...@ni...>:
> Perhaps Fernando or some other knowledgeable wx person can comment on
> the appropriate workaround if there is one.

Currently my workaround is to use Tk :(

Cheers,

f

What I was trying to say is that insofar as the SVG backend is a work in progress, the PyChart backend could be used an example to aid development. Just trying to be helpful :)

Chris

>>>>> "cfuller" == cfuller  <cf...@th...> writes:

    cfuller> A nice source for some SVG inspiration might be PyChart,
    cfuller> another python plotting system, that has a fully
    cfuller> functional SVG backend:
    cfuller> http://www.hpl.hp.com/personal/Yasushi_Saito/pychart.  I
    cfuller> like the looks/features of this package, but it lacks
    cfuller> interactivity/GUI support and relies on ghostscript for
    cfuller> rendering images.

Are you aware that matplotlib has an SVG backend already?  Jared
Wahlstrand submitted one back in late May, which I haven't announced
yet.  Jared what is the status on backend_svg

 - font support?

 - mathtext support?

 - image support?

JDH

>>>>> "cfuller" == cfuller  <cf...@th...> writes:

    cfuller> wx won't start up on my linux machine, running Fedora
    cfuller> Core 2 and a compiled-from-source wxPython 2.5.1. There
    cfuller> was some incompatability with the new GTK libraries,
    cfuller> since the wxPython rpm was comppiled on RH9. I'm guessing
    cfuller> the wx backend is having similar troubles, although I
    cfuller> compiled it from source, naturally. That's a long
    cfuller> compile, BTW!  The wx backend works for me at work, under
    cfuller> Server 2003 and the same version of wx. It still leaks,
    cfuller> although I upgraded to the .60b installation binary from
    cfuller> John's website. Compiling distutil packages under windows
    cfuller> is something I've yet to master, whether with the Borland
    cfuller> compiler or the (not so new) Visual C++ Tooolkit
    cfuller> 2003. Visual Studio just isn't something I can justify,
    cfuller> even if the lab would pay for it. Especially with the VC6
    cfuller> vs VC7 funny business. At least Tk stopped leaking!

Could you send me the script that is leaking?

    cfuller> Since I have a wx that works, its not so bad. I'll still
    cfuller> work on the FC2 issues, but I can see about that toolbar
    cfuller> addition as well. I should get around to installing
    cfuller> windows again at home, I've been putting off an upgrade
    cfuller> to XP, and my old win2k pro install is useless, after a
    cfuller> mobo upgrade.

I believe this is the bug Fernando Perez was writing about which is
specific to recent releases of wx that use private GTK symbols that
are no longer present in the gtk libs in Fedora core 2.  Here is a
snip from an email he sent me earlier on the subject.  As far as I
know, there is nothing we can do about it on the matplotlib side,
except perhaps check the wx/wxpython list to see if it has been fixed
yet in CVS, and agitate for a fix if not.  

Perhaps Fernando or some other knowledgeable wx person can comment on
the appropriate workaround if there is one.

From: Fernando Perez <Fer...@co...>
Subject: Re: matplotlib, ipython and other comments
To: John Hunter <jdh...@ni...>
Date: Wed, 09 Jun 2004 14:29:54 -0600
Organization: Applied Mathematics, University of Colorado at Boulder

...snip ...

> I'll look into this later.  My experience with WX and WXAgg is that
> both work under linux, but WX is a bit slow and buggy.  Is the problem
> you are describing Fedora specific?  (Sorry I can't easily read these
> links now since URL cut-and-paste from my xterm on OSX laptop to my
> browser window doesn't work).

No, the bug is in current WX.  Here's a traceback:

In [6]: import wx
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/fperez/<console>

/usr/lib/python2.3/site-packages/wx/__init__.py
      43 __revision__ = "$Revision: 1.1.2.4 $"[11:-2]
      44
---> 45 from wxPython import wx
      46
      47 _newnames = {}

/usr/lib/python2.3/site-packages/wxPython/__init__.py
      18 # Ensure the main extension module is loaded, in case the add-on modules
      19 # (such as utils,) are used standalone.
---> 20 import wxc
      21
      22 
#----------------------------------------------------------------------------

ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol: 
_gtk_accel_group_detach

Apparently the WX guys chose to use _gtk_* symbols which the GTK documentation 
_explicitly warned_ were private and could go away at any time.  Now, in the 
version of GTK shipped with Fedora they _did_ go away, so Wx broke.  This just 
needs to be fixed by the Wx team (maybe it already is in CVS, I'm using Wx as 
shipped with Fedora).  So don't worry about this, it will get fixed in time by 
those responsible.

wx won't start up on my linux machine, running Fedora Core 2 and a compiled-from-source wxPython 2.5.1. There was some incompatability with the new GTK libraries, since the wxPython rpm was comppiled on RH9. I'm guessing the wx backend is having similar troubles, although I compiled it from source, naturally. That's a long compile, BTW!

The wx backend works for me at work, under Server 2003 and the same version of wx. It still leaks, although I upgraded to the .60b installation binary from John's website. Compiling distutil packages under windows is something I've yet to master, whether with the Borland compiler or the (not so new) Visual C++ Tooolkit 2003. Visual Studio just isn't something I can justify, even if the lab would pay for it. Especially with the VC6 vs VC7 funny business. At least Tk stopped leaking!

Since I have a wx that works, its not so bad. I'll still work on the FC2 issues, but I can see about that toolbar addition as well. I should get around to installing windows again at home, I've been putting off an upgrade to XP, and my old win2k pro install is useless, after a mobo upgrade.

Chris

A nice source for some SVG inspiration might be PyChart, another python plotting system, that has a fully functional SVG backend: http://www.hpl.hp.com/personal/Yasushi_Saito/pychart.

I like the looks/features of this package, but it lacks interactivity/GUI support and relies on ghostscript for rendering images.