matplotlib-devel Mailing List for matplotlib (Page 551)

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John>   * clipping appears broken: arctest.py, legend_demo.py, and
    John> so on.  This used to work, right?

    John>   * dotted lines are solid: see any plot with grid(True),
    John> eg, log_test.py.  Ditto for dashed lines: eg, plot(t3,
    John> cos(2*pi*t3), 'r--') appears solid.

Both of these problems are arising from the select / unselect thing in
the GC.  Since these changes were in response to the double gc problem
which no longer exists, I'm simply going to 'pass' in select and
unselect for the next release (which fixes both problems) above.
backend wx now passes all the tests, except the known issues.

I also added some more of the dpi scaling functionality to wx
(linewidth and markersize via the new renderer method
points_to_pixels).  The last remaining area is dash size which is more
difficult since wx uses a constant for dash drawing rather than an ink
on/off approach.  Does wx also support on/off?  If I recall correctly,
you experimented with this but had a hard time getting it working right.

In any case the high res (eg dpi=300) wx output looks great.

There also seems to be an issue with getting the text bounding box
right with fontangles and fontweights that are not standard.  To
experiment with this, uncomment 'if 0' on or around line 416 is
axis.py and run text_handles.py or text_themes.py.  This will draw the
bbox around you text instance.

JDH

pypaint 0.3
-----------------
This module provides a light Python wrapper for libart written in C.  It
allows you to create static images quickly.  pypaint runs on both Linux and
Windows.

It only provides basic functionality at the moment - line drawing,
rectangles, polygons, arcs, fill, and simple font support (using freetype
1).  The images are output in PNG format.

There will be support for a pypaint backend in the next release of
matplotlib.

pypaint is available at http://sourceforge.net/projects/pypaint.  In
future, there will be a homepage up at http://pypaint.sourceforge.net

David Moore
Software Consultant
St. James Software
Phone: +27 21 424 3492
e-mail: da...@sj...

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004/02/06

>>>>> "David" == David Moore <da...@sj...> writes:

    David> Sorry, last email wasn't to the list.  From posts you've
    David> made, it looks like you've made some changes to pypaint.
    David> Do you want those committed before a pypaint release?
    David> Apart from that, I'm just tying up some loose ends, and
    David> then I'll be able to make the release - hopefully today,
    David> but maybe only Monday if you want your changes added.

I don't have anything to add.  I tried to get clipping working but
didn't succeed.  I think there are two problems

 1) libart wants to paths to be counter clockwise for clipping to work
    (at least that's what I was told on the libart list), and I don't
    think all the path constructors insure this, eg draw_arc.

 2) even when the paths are constructed properly, I think there is a
    problem in libart that causes clipping artifacts.

So I think you'll be fine going with what you've got for now.  It
would be great to get clipping worked out in the long run, but I don't
see any immediate solutions.

On the font front: as I mentioned earlier, I ported font.c to agg and
it's working.  For high resolution images it works great.  For small
images (eg, dpi=60) the fonts look pretty bad.  I think this is the
same for paint and agg, at least in the comparisons I've looked at.
This isn't surprising since the font code is the same.  The two areas
where small rasters come up are for web pages (which is where I assume
your interests are) and embedding in GUI applications (which is
important to me).

Is this why you want to upgrade to freetype2?  From my reading of some
of the docs there, this is one thing that freetype2 does better.

JDH

On Saturday 14 February 2004 8:03 am, you wrote:
> Thanks for the pointers.
>
> On Friday 13 February 2004 9:20 pm, you wrote:
> > I made some progress!
>
> [snup]
>
> > The bug was a line I introduced when I added some more print
> > debugs
>
> I had fixed this one...
>
> > The front end change that is causing your problems is that I now pass
> > a gcedge and a gcface.  I used to pass a gcface and a face color.
> > Maybe I'll revert to that.
> >
> > When I instantiate a gcedge and a gcface on the front end, you make 2
> > calls to new_gc
> >
> >     def new_gc(self):
> >         """
> >         Return an instance of a GraphicsContextWx, and sets the current
> > gc copy """
> >         DEBUG_MSG('new_gc()', 2, self)
> >         self.gc = GraphicsContextWx(self.bitmap, self)
> >         assert self.gc.Ok(), "wxMemoryDC not OK to use"
> >         return self.gc
> >
> > I think initing 2 GCs with the same bitmap is causing the problem.  If
> > you see an easy backend solution, that would be ideal.  If not, I
> > could re-refactor the frontend to be like it was: pass a gcedge and a
> > facecolor.
>
> This is, indeed, illegal in wx. It sometimes works under Windows, but
> consistently fails (dramatically) under Linux (at least for wxGtk).

To be more exact about what happens, here is the synopsis:

In patches.py, Patch._draw() instantiates two gc instances

    def _draw(self, renderer, *args, **kwargs):

#here=============>
        gc = renderer.new_gc()                                   
        gc.set_foreground(self._edgecolor)
        gc.set_linewidth(self._linewidth)
        gc.set_alpha(self._alpha)
        if self._clipOn:
            gc.set_clip_rectangle(self.bbox.get_bounds())
        if not self.fill: gcFace = None
        else:
#and here===========>
            gcFace = renderer.new_gc() 
            gcFace.set_foreground(self._facecolor)
            gcFace.set_alpha(self._alpha)
        self._derived_draw(renderer, gc, gcFace)

Each call to backend_wx.py RendererWx.new_gc() does the following:

        self.gc = GraphicsContextWx(self.bitmap, self)
        assert self.gc.Ok(), "wxMemoryDC not OK to use"
        return self.gc

But instantiating a GraphicsContextWx does:

    def __init__(self, bitmap, renderer):
        GraphicsContextBase.__init__(self)
        wxMemoryDC.__init__(self)
        DEBUG_MSG("__init__()", 1, self)
        # Make sure (belt and braces!) that existing wxDC is not selected to
        # to a bitmap.
        if GraphicsContextWx._lastWxDC != None:
#the gcEdge gets selected into a NULL bitmap here
            GraphicsContextWx._lastWxDC.SelectObject(wxNullBitmap)
        self.SelectObject(bitmap)
        self.SetPen(wxPen('BLACK', 1, wxSOLID))
        self._style = wxSOLID
        self.renderer = renderer    
        GraphicsContextWx._lastWxDC = self

You will note that in order to enforce the wx rule that no more than one 
wxMemoryDC can be selected into a bitmap, I ensure that the last wxMemoryDC 
instance activated is selected to a wxNullBitmap.

In the case of the above code, this means that the gc representing the 
rectangle has already been selected to a NULL bitmap. When you try to draw to 
this, an exception is generated within the C++ code which is not propagated 
back up to the Python layer. Unfortunately, the assert() calls don't help 
much here as each gc instance is OK when it is constructed.

I'm afraid I'd missed the significance of the change from a facecolor to a 
gcFace for fill colours.

> I'll see if I can come up with any ideas, but passing a gcedge and
> facecolor is likely to be simpler to get to work reliably.

I have thought about this, and to only other option I can think of is for me 
to select between 'currently active' gc instances as required. Obviously, 
this would probably slow backend_wx down, but I'm not yet sure what the 
performance hit will be. Let me try it...

[an hour or so later...]

Attached is a backend_wx which seems to work with most of the examples I've 
tried (Linux only - expect Windows to work as it's generally better behaved 
than wxGtk, but would be nice if someone would try it.

Some issues (for now):
- Clipping seems to be broken (c.f. arctest.py)
- Object picker demo doesn't work (haven't implemented this functionality)
- Some types of dotted lines are not working properly (c.f. subplot_demo.py)
- embedding_in_wx doesn't work - due to some of the recent API changes. I'll 
fix this one pretty soon - it shouldn't be much work.
- It's about 20% slower than the previous implementation in which only one GC 
was active at a time.

Not sure if the dotted lines and clipping are down to information being lost 
when I switch between gcs - I'll have to look into this, but the attached 
will be a good start for getting things to work on wx again.

John, I'll leave it as your call whether you want to switch the API back to 
using a facecolor instead of a gcFace. It would be better from the wx 
perspective, but there may be good reasons for doing otherwise on other 
backends. 

There are a couple of optimisations I can probably make to speed things a 
little if we stick with the current API -it should be possible to do 
something slightly more intelligent than simply selecting a bitmap at the 
start of each call, and deselecting it afterwards - although, as noted above, 
wxMemoryDC seems to be extremely fragile under wxGtk - not sure why.

I have checked the attached into CVS for now, but we may have the usual 
'mirror update' issue.

Regards

Jeremy

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:

    Vittorio> I have rebuild the package with support for gtkgd.  I
    Vittorio> have tried to build also the agg backend, but I can't
    Vittorio> find the source package for this library! I've found two
    Vittorio> version: one from http://antigrain.com and another from
    Vittorio> scipy cvs, but seems that there are some missing headers
    Vittorio> when I compile the backend.  I have also packaged the
    Vittorio> gdmodule from
    Vittorio> http://newcenturycomputers.net/projects/gdmodule.html
    Vittorio> and the ttfquery module from
    Vittorio> http://sourceforge.net/projects/ttfquery/, all the debs
    Vittorio> are on http://anakonda.altervista.org/debian/

Wow, amazing work.  

You may want to look at the header of matplotlib.backends.backend_agg
- this includes some install instructions, where to get agg, etc...

However, that may not be necessary.

I have built a new sdist that has all the prereqs for agg built in
(fonttools, ttfquery, and agg2).  You just have to set BUILD_AGG in
setup.py and it should build, as long as your compiler is fairly
recent.  I'll leave it to you whether you want to use debian to get
fontools and ttfquery, or use the ones included with matplotlib.  I
stripped all the fluff out of those 3 packages and with everything
included the sdist is still under a megabyte.

  http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50p.tar.gz

I used this to build an all-in-one win32 installer, which will be nice
because now win32 users with Numeric can make PS and PNG plots out of
the box (zlib, libpng, freetype are statically built in).

I'm going to upload the snapshot if you want to experiment with it.  I
should warn you though: I forgot yesterday that there is still a
critical bug in wx that must be repaired.  Thus there will be one more
revision following this one.  (Sorry)

JDH

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Hunter ha scritto:
>
> I have a couple of favors to ask of you.  The 0.50e release on the web
> site that you built against was an alpha release of the 0.50 series
> and a fair number of features, optimizations and bug fixes have been
> added since then.  The current snapshot has been well tested and is in
> good shape - would you be willing to build the package one more time
> against it?
>
>   http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50m.tar.gz
>
> Now a couple of questions.  I need to update the debian section of the
> web site.  Could you write something explaining how a relatively
> novice debian user would go about getting python-matplotlib?  Ie, what
> would they need to put in /etc/apt/sources.list, what commands would
> they need to issue from the shell, which of the backends are
> installed, etc...  How do you handle the various backends, eg, gd, wx,
> pygtk and so on.
>
> Just to give you an idea of how much has changed since the 0.50e alpha
> release, in addition to the aforementioned bugs and optimizations,
> there are 2 new backends (paint and agg), a new Table class, and a new
> matlab function table to interface to it, and several examples.  Note
> if you do rebuild, there is a src dir you'll want to include.
>

I have rebuild the package with support for gtkgd.
I have tried to build also the agg backend, but I can't find the source package
for this library! I've found two version: one from http://antigrain.com and
another from scipy cvs, but seems that there are some missing headers when I
compile the backend.
I have also packaged the gdmodule from
http://newcenturycomputers.net/projects/gdmodule.html and the ttfquery module
from http://sourceforge.net/projects/ttfquery/, all the debs are on
http://anakonda.altervista.org/debian/

I can write some documentation about debian packages required, once I've tested
them, but only for the next weekend, bye


- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFALOhdpT6bvDtyXOIRAiQGAKDDQCrh0sELN09vI2dKYVfTKZ9H4ACgr8o2
ezklwMSi/Ke3zY5kK8DWwsI=
=SX+C
-----END PGP SIGNATURE-----

Almost all of the backends (save postscript) either support freetype
or are capable or supporting it.  We need a good cross-platform
freetype font finder package.  Right now, we have fonttools and
TTFQuery, which get the job done.  But they bring a lot of extra
installation overhead.

For the postscript backend, I wrote a standalone AFM parser which has
worked well - the alternative was to require fonttools, which is
larger than all of matplotlib combined.  I would like to have the same
for TTF files - a small, free standing module with no extrinsic
dependencies that we can ship with matplotlib.

A introduction to the ttf specification can be found here
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter08.
We don't need much out of these files: things like character sizes,
kerning distances, etc, are already handled by the freetype extension
modules, eg, paint.font (which I also used for agg).  

What we need is for someone to identify the relevant *.ttf dirs on the
major platforms (you can extract most of this information from
TTFQuery), and parse enough of the ttf file to get family name, font
style, weight, etc....  You could either pull out the relevant bits
from fonttools and ttfquery or just roll your own.  Ideally, you
should be able to take a matplotlib.text.Text instance and returns the
ttf file which is the closest match for you on your system, falling
back on Vera (which ships with matplotlib) as the default.

I notice on
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter08#3054f18b
there is a field for "Postscript name for the font" which would be
nice to incorporate for backend switching (saving PS from GTK,
etc...).

Anyway, it would be a very useful addition to matplotlib, and would
speed the process of standardizing fonts across the backends.

JDH

Attached is a new version of backend_ps.py with two new functions,
landscape() and portrait().

Someone who actually understands post-script should check these fixes
out -- I know next to nothing about it, but the fixes seem to do the
trick, although I'm sure there is some other incantation I'm supposed to
put in the postscript so that viewers realise it is landscape and show
it that way.

Also attached is a new version of axis.py with a very minor mod to
format_tickval that ensures that the plot doesn't end up with labels
like: 199999999 in the case where the tickloc is just a shade under a
whole number.

John


On Tue, 2004-02-10 at 15:05, John Hunter wrote: 

> >>>>> "John" == John Gill <jn...@eu...> writes:
> 
>     John> I have some plots I'd like to print out and they would make
>     John> better use of the paper if they were done landscape.
> 
>     John> Can the postscript backend do this?
> 
> Hi John,
> 
> I haven't had time to take a close look at this.  My initial
> suggestions is to experiment with the paper size
> 
> import matplotlib
> matplotlib.use('PS')
> import matplotlib.backends.backend_ps as backend_ps
> backend_ps.defaultPaperSize = 11,8.5  # default is 8.5, 11
> 
> You may also have to specify a landscape portrait at print time, or
> rotate it.
> 
> I'll take a closer look later.
> 
> JDH
> 

>
> On the topic of releases: David, my target date is early next week.
> Do you think you can get pypaint up by then?
>
> Thanks again,
> JDH
>

Hi John,

Sorry, last email wasn't to the list.  From posts you've made, it looks like
you've made some changes to pypaint.  Do you want those committed before a
pypaint release?  Apart from that, I'm just tying up some loose ends, and
then I'll be able to make the release - hopefully today, but maybe only
Monday if you want your changes added.

thanks,
David Moore

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004/02/06

>>>>> "Vittorio" == Vittorio Palmisano <re...@em...> writes:

    Vittorio> Ok, I have fixed this problems, now "lintian -i
    Vittorio> python-matplotlib_0.50-1_i386.changes" doesn't say
    Vittorio> nothing.  I have updated the files on my repository, bye

Hi Vittorio, thanks a bunch for doing this.  A lot of people have
asked for this, and there's been incremental progress here and there,
but I'm glad to see you got everything done.

I have a couple of favors to ask of you.  The 0.50e release on the web
site that you built against was an alpha release of the 0.50 series
and a fair number of features, optimizations and bug fixes have been
added since then.  The current snapshot has been well tested and is in
good shape - would you be willing to build the package one more time
against it?

  http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50m.tar.gz

Now a couple of questions.  I need to update the debian section of the
web site.  Could you write something explaining how a relatively
novice debian user would go about getting python-matplotlib?  Ie, what
would they need to put in /etc/apt/sources.list, what commands would
they need to issue from the shell, which of the backends are
installed, etc...  How do you handle the various backends, eg, gd, wx,
pygtk and so on.

Just to give you an idea of how much has changed since the 0.50e alpha
release, in addition to the aforementioned bugs and optimizations,
there are 2 new backends (paint and agg), a new Table class, and a new
matlab function table to interface to it, and several examples.  Note
if you do rebuild, there is a src dir you'll want to include.

On the topic of releases: David, my target date is early next week.
Do you think you can get pypaint up by then?  

Thanks again,
JDH

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jochen Voss ha scritto:
> Hi Vittorio,
>
>
> Thank you for the package.  I had a short look at it.
> Some comments:
>
> 1) Somehow the python-matplotlib-0.50/build directory sneaked
>   into your diff file.  You should remove it from your sources
>   and rebuilt your package.
>
> 2) You should check your package with lintian.
>   Calling "lintian -i python-matplotlib_0.50-1_i386.changes"
>   gives a lot of useful hints.
>
> I hope this helps,
> Jochen

Ok, I have fixed this problems, now "lintian -i
python-matplotlib_0.50-1_i386.changes" doesn't say nothing.
I have updated the files on my repository, bye

- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFALBMapT6bvDtyXOIRAotMAKCKjRsSkEqW1+ZghHsbPTPSkxiK5gCfcse1
nTVo7VRSpn42CrynvFDGNKY=
=yfL1
-----END PGP SIGNATURE-----

Hi Vittorio,

On Thu, Feb 12, 2004 at 11:14:19PM +0100, Vittorio Palmisano wrote:
> I've made a Debian package for matplotlib and I've put it at:
> http://anakonda.altervista.org/debian/

Thank you for the package.  I had a short look at it.
Some comments:

1) Somehow the python-matplotlib-0.50/build directory sneaked
  into your diff file.  You should remove it from your sources
  and rebuilt your package.

2) You should check your package with lintian.
  Calling "lintian -i python-matplotlib_0.50-1_i386.changes"
  gives a lot of useful hints.

I hope this helps,
Jochen
--=20
http://seehuhn.de/

Hello,
I've made a Debian package for matplotlib and I've put it at:
http://anakonda.altervista.org/debian/

I've read some specification for dependencies from http://bugs.debian.org/206691,
this is my first package and so there are some (many?) things to fix.
I think that the package may also include the api documentation generated with pydoc.




-- 
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org

On Tue, 2004-02-10 at 16:30, John Hunter wrote:
> I just made a minor change in the backend API.  The faceColor argument
> (formerly a color arg) for draw_rectangle, draw_arc, etc... is now a
> graphics context instance.  I updated all the backends in CVS.  
> 
Hi John,

I'm working with Perry Greenfield's group on a Tkinter/Paint backend for
matplotlib.  I noticed today that the paint facecolor had changed to
black.  Looking into it,  there were a few more edits to
backend_paint.py needed as a result of the interface change above.  I
also noticed that the paint version of draw_polygons needed a little
code to get it working.  Attached is a patch for both.

Regards,
Todd

-- 
Todd Miller <jm...@st...>

The agg backend

  Features that are implemented

    * capstyles and join styles
    * dashes
    * linewidth 
    * lines, rectangles, ellipses, polygons
    * clipping to a rectangle
    * output to RGBA and PNG
    * alpha blending
    * DPI scaling -  (dashes, linewidths, fontsizes, etc)
    * freetype1

  TODO:
     * use ttf manager to get font - right now I just use Vera

  INSTALLING 

   Grab the latest matplotlib from
   http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.50l.tar.gz

  REQUIREMENTs

    python2.2+
    Numeric 22+
    agg2 (see below)
    freetype 1
    libpng
    libz ?
    
  Install AGG2 (cut and paste below into xterm should work)

    wget http://www.antigrain.com/agg2.tar.gz
    tar xvfz agg2.tar.gz
    cd agg2
    make

    (Optional) if you want to make the examples:
    cd examples/X11
    make

  Installing backend_agg

   Edit setup.py: change aggsrc to point to the agg2 src tree and
   replace if 0: with if 1: in the backend_agg section

   Then just do the usual thing: python setup.py build

   Please let me know if you encounter build problems, and tell me
   platform, gcc version, etc...  Currently the paths in setupext.py
   assume as linux like filesystem (eg X11 include dir, location of
   libttf, etcc) so you may need to tweak these.  

  Using agg backend

    python somefile.py -dAgg   

  or

    import matplotlib
    matplotlib.use('Agg')
      
Let me know how it works out!  Note also that backend agg is the first
backend to support alpha blending; see scatter_demo2.py.

JDH

John,

Thanks for all the fixes.  Having data_table as matplotlib.matlab.table
is good + also on the axes.

I've attached my latest demo script -- was in the process of trying to
simplify the example for you, but have been a bit busy the last couple
of days.

I split the colour generating stuff into colours.py -- might be useful
to have this sort of thing available somewhere in matplotlib.

Re: the numbers in the table not matching up in the demo.  The numbers I
put in the table are the total height of the columns, not just the
incremental heights (the place where I use these things are to show loss
statistics at different return periods + the users want to see the full
numbers not the incremental stuff).   I've just re-read this para and it
is about as clear as mud, so yell if it isn't making sense alongside the
picture.

John

On Wed, 2004-02-11 at 19:07, John Hunter wrote:

> >>>>> "John" == John Gill <jn...@eu...> writes:
> 
>     >> If I could impose on you one more time.  I would like to add a
>     >> table screenshot to the web page.  Something along the lines of
>     >> the first table example you sent (with the stacked bar chart)
>     >> but using data_table to build the table.  The code should be as
>     >> simple as possible since we want to emphasize the ease of use.
>     >> Do you have some data you can use to make a table that can be
>     >> displayed on the web?  I have a data dir in the examples dir
>     >> that I use to distribute data.
> 
> In anticipation of the 0.50 release, I did some reorganization of the
> table code to make it more consistent with other matplotlib commands.
> Eg,, data_table is now an axes function axes.table and at
> matplotlib.matlab command "table".
> 
> 
> 
> ______________________________________________________________________
> 
> I tried to adapt your various examples into a single demo using the
> new table command.  It works ok, but the numbers in the table don't
> seem to always correspond to the respective sizes of the table.  I
> don't fully have my head around the example - perhaps you can advise?
> 
> 
> 
> ______________________________________________________________________
> 
> Thanks!
> 
> JDH

On Tuesday 10 February 2004 9:30 pm, John Hunter wrote:
> Unfortunately Jeremy, there now appears to be a bug in wx.  I can't
> tell if it was something I did or something that was there already,
> because with wx swallowing the exceptions, I can't find it!  I also
> added a few more debug print messages to functions that don't have
> them already, but still couldn't track it down.  Sorry for the
> trouble.

I have found the location of the error, but have not yet determined how the 
problem arises:

Basically, when savefig() is called by the script, the first draw_rectangle() 
call fails an assert gc.OK() statement. I have not determined why Python is 
not receiving the AssertException - my conjecture is that the call to gc.Ok() 
is causing an exception in the C++ code - I will probably have to use a debug 
version of the wx libraries and a debugger to verify this.

The stack frame when the exception is raised is:

__main__ #40
matplotlib.matlab.savefig #798
matplotlib.backends.backend_wx #812
matplotlib.artist.draw #86
matplotlib.figure._draw #65
matplotlib.artist.draw #86
matplotlib.patches._draw #76
matplotlib.patches._derived_draw #154
matplotlib.backends.backend_wx #403

I'll let you know how I get on...

Jeremy

>
>
>
> I am doing some work on an agg backend, and would like to include
> freetype support.  I've been looking into borrowing heavily from
> paint's approach.  I remember David that you said you were looking
> into upgrading to freetype 2, and am wondering if you've had any luck
> here, if this looks doable, what the time frame would be etc...

I haven't had a chance yet.  Real job has been very busy, but that should
change soon.  Sorry about the delays.

>
> scipy has a freetype 2 wrapper, but it has a lot of scipy dependencies
> built in so it looks like it would take some work to tease them out.
>
> On a separate note, I was thinking about doing a matplotlib-0.50 (to
> the wider python-list, scipy-list, etc...) release in the near future,
> but want to wait until pypaint is up.  I see that the sf site now
> exists.  When do you expect to be live?  Will you have some install
> instructions for linux and win32 users?

The site came up late last night (for me).  Today, I'm just going to import
files etc.  I can look at install instructions and so on maybe tomorrow.

>
> Thanks,
> JDH
>
Sorry about the long waits,

David Moore
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004/02/06

> 
> Note to any wx savvy readers!  Jeremy and I have been struggling over
> the tendency of wx to eat exceptions in a way that we can't recover.
> If anyone knows how to disable this in wxpython, please contact us.
> 
> JDH
> 
> 

This might put you on the right track:
http://lists.wxwindows.org/archive/wxPython-users/msg10801.html

HTH,
David Moore

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.580 / Virus Database: 367 - Release Date: 2004/02/06

I am doing some work on an agg backend, and would like to include
freetype support.  I've been looking into borrowing heavily from
paint's approach.  I remember David that you said you were looking
into upgrading to freetype 2, and am wondering if you've had any luck
here, if this looks doable, what the time frame would be etc...

scipy has a freetype 2 wrapper, but it has a lot of scipy dependencies
built in so it looks like it would take some work to tease them out.

On a separate note, I was thinking about doing a matplotlib-0.50 (to
the wider python-list, scipy-list, etc...) release in the near future,
but want to wait until pypaint is up.  I see that the sf site now
exists.  When do you expect to be live?  Will you have some install
instructions for linux and win32 users?

Thanks,
JDH

I just made a minor change in the backend API.  The faceColor argument
(formerly a color arg) for draw_rectangle, draw_arc, etc... is now a
graphics context instance.  I updated all the backends in CVS.  

Unfortunately Jeremy, there now appears to be a bug in wx.  I can't
tell if it was something I did or something that was there already,
because with wx swallowing the exceptions, I can't find it!  I also
added a few more debug print messages to functions that don't have
them already, but still couldn't track it down.  Sorry for the
trouble.

Note to any wx savvy readers!  Jeremy and I have been struggling over
the tendency of wx to eat exceptions in a way that we can't recover.
If anyone knows how to disable this in wxpython, please contact us.

JDH

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> See attached.  table.py now has dataTable which does the
    John> autogenerating of tables given cells, rows and column stuff
    John> and tries to do sensible things if only a subset is actually
    John> supplied.

    John> data_table_demo.py is an example of dataTable in action.

    John> I've included the latest version of cell.py 'cos I think
    John> I've added more to that in the last 24 hours as well.

I made a two minor changes

 * dataTable is renamed to data_table to be consistent with matplotlib
   function naming.

 * I moved Cell into table.py and removed cell.py

If I could impose on you one more time.  I would like to add a table
screenshot to the web page.  Something along the lines of the first
table example you sent (with the stacked bar chart) but using
data_table to build the table.  The code should be as simple as
possible since we want to emphasize the ease of use.  Do you have some
data you can use to make a table that can be displayed on the web?  I
have a data dir in the examples dir that I use to distribute data.

    John> re: including this in the next release, that would be
    John> excellent.

Great -- it's in CVS.  I took the liberty of adding 

  Author    : John Gill <jn...@eu...>
  Copyright : 2004 John Gill and John Hunter
  License   : matplotlib license

Thanks a lot - this is a great addition.

JDH

See attached.

table.py now has dataTable which does the autogenerating of tables given
cells, rows and column stuff and tries to do sensible things if only a
subset is actually supplied.

data_table_demo.py is an example of dataTable in action.

I've included the latest version of cell.py 'cos I think I've added more
to that in the last 24 hours as well.

re: including this in the next release, that would be excellent.

john  


> All very nice.  Two things I think would make a nice addition.  You've
> provided a great selection of default locations.  It shouldn't be too
> hard to allow 'loc' to be None, and let the user define a bbox (left,
> bottom, width, height) in 0-1 coords to place the table wherever they
> want it.
> 
> Ie, use
> 
> class Table
>     def __init__(self, axis, loc=None, bbox=None):
> 
> The other thing that might would be a nice addition is a function to
> autogenerate tables.  Eg, you provide it a list of col header strings,
> row header strings, color args and an MxN array of cell text strings,
> and it does the dirty work of actually building the table for you.  If
> col header strings is empty, don't do the row at -1, etc...
> 
> Thanks!  With your permission, I'll include it in the next matplotlib
> release.
> 
> JDH
> 
> 

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> John, Here is another go at the tables.

Very nice!  Soon we'll be able to write matplotlib_excel :-)

    John> I've created a cell object (see cell.py).  This is just a
    John> rectangle that has some (optional) text associated with it.

A minor comment.  Derived artist should implement '_draw', nor 'draw'
as the Artist Base implements the draw method, caches the renderer
instance and then calls _draw.  Ie, you want

    def _draw(self, renderer, *args, **kwargs):

        # draw the rectangle
        # use _draw here since this is a base class
        Rectangle._draw(self, renderer, *args, **kwargs) 

        # position the text
        self._set_text_position()
        self._text.draw(renderer)  # use draw here

I noticed I made the same mistake in text.Text.  The 'draw' method
there should be renamed _draw.

The motivation here is that you can redraw any artist w/o access to
the renderer since the Artist base has stored it and will use it if
renderer is None

  instance.draw()  # instance is derived from Artist
  
    John> A table is now not much more than just a collection of
    John> cells.

All very nice.  Two things I think would make a nice addition.  You've
provided a great selection of default locations.  It shouldn't be too
hard to allow 'loc' to be None, and let the user define a bbox (left,
bottom, width, height) in 0-1 coords to place the table wherever they
want it.

Ie, use

class Table
    def __init__(self, axis, loc=None, bbox=None):

The other thing that might would be a nice addition is a function to
autogenerate tables.  Eg, you provide it a list of col header strings,
row header strings, color args and an MxN array of cell text strings,
and it does the dirty work of actually building the table for you.  If
col header strings is empty, don't do the row at -1, etc...

Thanks!  With your permission, I'll include it in the next matplotlib
release.

JDH

John,

Here is another go at the tables.

I've created a cell object (see cell.py).  This is just a rectangle that
has some (optional) text associated with it.

A table is now not much more than just a collection of cells.

You just create the table and then add all the cells.   For each cell
you specify the row and column.  Negative column numbers are allowed,
which is handy for things like row labels.

See table_demo3.py for an example of how it works.   The demo also
includes some stuff to help with coming up with nice (?) pastel shades
to use as colours.

I've also got an option that allows you to specify that a particular
column should have its width worked out automagically based on the text
in the cells in the column (again see the demo).

axes.py is almost the same as the last version i sent you, the only
change is this little bug fix:

304c305
<             (iterable(color) and len(color)==3 and len(x)!=3) or
---
>             (iterable(color) and len(color)==3 and len(left)!=3) or

John