matplotlib-devel Mailing List for matplotlib (Page 2)

>
>
>
> 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

>>>>> "Jon" == Jon Peirce <jw...@ps...> writes:
 Jon> John, loving matplotlib - thx.
 Jon> Was using pcolor today but needed a gray colormap rather than
 Jon> jet. Made my own version (see attached) using a class
 Jon> Colormap with attribute color (which can be set to
 Jon> 'jet'). Seemed a bit more adaptable and more like matlab. I
 Jon> linked ColormapJet back to this class so that other people's
 Jon> code wont break (hopefully ;) ). Probably worth allowing
 Jon> users to supply there own as an array too, but I didn't have
 Jon> time to do that today.
I've been wanting to include multiple colormaps, so this is a start in
the right direction. A word of warning: some versions of Numeric are
broken with 'from __future__ import division'
 from __future__ import division
 ...snip...
 self.red = arange(self.N+1)/self.N
It's safer to do
 self.red = 1/self.N*arange(self.N+1) 
or
 self.red = divide(arange(self.N+1), self.N)
 Jon> On a different topic slightly, I wonder if it would be worth
 Jon> having a plot type based on image widgets. For large arrays
 Jon> pcolor is still very slow under gtk. Maybe either using image
 Jon> widgets for pcolor itself or having a different plot type
 Jon> (like matlabs 'image' or 'imagesc').
I don't think a specialized plot type or image widget is the way to
go, since it wouldn't port across backends very well. The plot
commands are fairly high level and are used to construct the lower
level graphics primitives. 
I think it better perhaps to introduce some new graphics primitives
(on the same level as line, patch, text) that handle 2D arrays and
colormaps efficiently. The cases I would like to be able to handle
are
 1) 2D image data: eg, RGB or plain old image files such as PNG
 2) 2D scalar data: points with colormap
 3) 2D scalar data: rectangle patch + colormap + optional gradient
 interpolation
In the existing design of matplotlib, the backends don't handle
transformations, scaling, etc... Consistent with this, we could
provide frontend code to take existing image data (construed broadly
to cover all the cases above), scale it to the axes display
coordinates, do the interpolation as necessary, and construct an MxN
array (axes window is MxN pixels) of RGBA data (RGBA is in normalized
0,1 scale). In other words, we agree on a single image data structure
all implemented in extension code, and then make the backends
implement a method to handle that structures in the same way they have
to now handle a rectangular patch.
Eg, we would need only one additional backend method
 renderer.draw_rgba(imageData)
and it only has to do a little extra work to render it. In GTK all
that would be required is to scale the RGB by 65536 and use the GDK
draw rgb method.
We would definitely want to use some decent image library to do the
frontend scaling, interpolation, file loading, etc. libart and agg
have been discussed on and off list lately as candidates. VTK is also
a possibility. Although it is primarily 3D library, it also has
support for all the 2D stuff you can imagine and everything else too.
VTK is a big and hairy package, but it runs everywhere, does
everything well, and opens the door for going 3D.
I've had some discouraging experiences with libart over the last few
days. In trying to implement clipping for the paint backend, I've
come across some known libart numerical instabilities, and in my
questions to the libart list I've been steered to agg by other
frustrated libart users. 
JDH

John,
loving matplotlib - thx.
Was using pcolor today but needed a gray colormap rather than jet. Made 
my own version (see attached) using a class Colormap with attribute 
color (which can be set to 'jet'). Seemed a bit more adaptable and more 
like matlab. I linked ColormapJet back to this class so that other 
people's code wont break (hopefully ;) ). Probably worth allowing users 
to supply there own as an array too, but I didn't have time to do that 
today.
On a different topic slightly, I wonder if it would be worth having a 
plot type based on image widgets. For large arrays pcolor is still very 
slow under gtk. Maybe either using image widgets for pcolor itself or 
having a different plot type (like matlabs 'image' or 'imagesc').
all the best
Jon
-- 
Jon Peirce
Nottingham University
+44 (0)115 8467176 (tel)
+44 (0)115 9515324 (fax)
http://www.psychology.nottingham.ac.uk/staff/jwp/

> John> Hi John, I've moved on a fair bit with this, still quite a
> John> way to go.
> 
> Nice work. table_demo.py looks fairly wild -- prone to induce
> seizures -- but table_demo2.py is nice. 
I do a lot of this work on the train in and out of work -- have to be
careful running table_demo.py in case anyone is watching the screen.
> John> axes.patch is a patch to axes.py that adds table support.
> 
> Could you provide context diffs, or just the whole file. I can diff
> it myself or just copy and paste the relevant code.
I've attached my version of axes.py.
Thanks for the axes tip -- that is much better.
One other glitch that is showing up is when I resize the window (I'm
using the GTK backend) for table_demo2.py the table with the row labels
goes out of alignment with the other table -- any ideas what is causing
that?
I like the coloured patches with text idea -- i'll do some experiments
and see how it looks. One thought I had is to turn the colours into
light pastel shades so that dark text still stands out.
John

David Moore has stealthily written a paint backend for matplotlib.
paint is a libart wrapper
 http://www.levien.com/libart
The official libart documentation is sparse, but I found these
documents very helpful
 http://www.gnome.org/~mathieu/libart
 http://developer.gnome.org/doc/books/WGA/graphics-libart.html
In a nutshell, libart is a svg oriented, high performance, 2D graphics
engine that supports lots of nifty features. The paint backend
exposes some of them, and David has been extending it to expose more.
Look for pypaint.sourceforge.net in the near future. The official
release of paint at http://www.object-craft.com.au/projects/paint
won't work with backend_paint. David can you announce here when you
release it? If anyone wants to test it out before then, perhaps you
should contact David at da...@sj....
The latest version of backend_paint.py can be obtained from CVS. Here
is a status list of known issues
 * Text and linewidths don't scale with DPI - FIXED
 
 * No dots or dashed lines - FIXED
 * Patch edge colors not displayed - FIXED
 * circle center locations off - FIXED
 * font manager support not included - OPEN. I moved the gd truetype
 font manager stuff to matplotlib.backends.ttf_font_manager so it
 could be adapted for use with all true type backends, but haven't
 incorporated this into the paint backend. The default font is
 Vera.
 * no clipping - OPEN. The libart function art_svp_intersect is used
 for intersecting arbitrary sorted vector paths (clipping), but this
 needs to be exposed in the paint wrapper.
 * draw_lines moved into the paint extension module - OPEN.
 draw_lines is probably the most common operation performed in
 matplotlib, sometimes with very long arrays, and it would be a big
 gain and an easy port to do this at the C level. the function
 should probably just construct and return a path that can be dashed
 or stroked as needed at the python level.
In the longer term, I would like to be able to support some path
operations at the renderer level. Now that matplotlib has two vector
oriented backends (paint and postscript) and I would like to add PDF
and SVG, it would be nice to support some path operations in the front
end, to take advantage of their sophisticated drawing capabilities.
The question is: how to bring the other backends along?
JDH

>>>>> "John" == John Gill <jn...@eu...> writes:
 John> Hi John, I've moved on a fair bit with this, still quite a
 John> way to go.
Nice work. table_demo.py looks fairly wild -- prone to induce
seizures -- but table_demo2.py is nice. 
 John> axes.patch is a patch to axes.py that adds table support.
Could you provide context diffs, or just the whole file. I can diff
it myself or just copy and paste the relevant code.
 John> Currently you have to specify the column widths for the
 John> table. Really two cases should be supported: allow the user
 John> to specify the widths (this is needed so you can line up
 John> tables with bar plots) and allow the Table to auto-adjust
 John> the widths to make everything just big enough for whatever
 John> text is present (this is handy for legend type stuff). I've
 John> done nothing for auto-guessing of widths as yet.
It can be a pain. I think you're taking the right approach - do the
easy case first. As you probably noticed, the legend does some
autolayout using bboxes and you can emulate this code if you want to
go this route.
 John> I've made the grid within the tables an option + I think
 John> with a little more work legend.py could just use table.py to
 John> do what it has to do.
 John> There is an ugly hack, rowOffset that I use in
 John> table_demo2.py to get the row labels to align with the
 John> appropriate data. My idea was that it might be simpler to
 John> have a basic table object and then build up more complicated
 John> stuff such as including row-labels by creating multiple
 John> tables.
 John> Currently I can't decide whether i wouldn't be better trying
 John> to support the row/column labels all in the one object -- I
 John> suspect this is the way to go since it is easier to get
 John> things to line up this way rather than trying to align lots
 John> of separate tables (eg if i start supporting different fonts
 John> for different tables then we'll really be in trouble).
 John> Now as I said there is still lots to do here.
 John> There are all sorts of minor and not so minor alignment
 John> issues to address -- a lot of these I think I can solve by
 John> paying a bit more attention to the legend.py code.
 John> The most significant problem at the moment is that the
 John> tables are getting clipped -- I'm not sure how I control the
 John> size of the border around the axes.
You need to manually set the axes. The figure size is fixed and the
axes take up a fixed proportion of the figure. In table_demo.py, put
the following at the top of your code
 axes([0.3, 0.3, 0.6, 0.6])
The default subplot(111) is much bigger than this and you can't fit
the whole axes and the table on the figure.
 John> I'd also like to make it so you can specify that text should
 John> be left/right/centre aligned.
 John> There is also quite a bit of work to do on the actual
 John> interface to the table objects, basically making them smart
 John> about the parameters they are given so that simple cases
 John> just work by magic. They are in danger of sprouting a
 John> plethora of options + no-one will be able to figure out how
 John> to use the things.
 John> Anyway, so far it has been fun working with this stuff.
Last night I had a completely different idea that might be very nice.
Create a Cell object that subclasses patch.Rectangle but is
initialized with text. draw the text in the cell. You could easily
layout the text within the cell to be right, left, top, bottom,
justified using the text alignment properties. You would also have
full control of the face and edge color of the cells, so you could
have alternating colors for the rows, etc. Or you could make the
inner cells have a white face color and black edge color (standard
table look) or a white edge color. Ie, you would have total control.
You would build the table by placing a bunch of cells in rows and
columns.
One potential downside of this approach is that it might be hard to
see text over a dark color, and your current side-by-side approach
avoids this. But you could workaround this by having a colored cell
with no text next to a while cell with text, and so on. The other
downside is that it would mean more or less starting over. My guess
is that it would be a clean design and easy to implement.
If you go this route, I might advise you not to follow the legend
example and your current approach which is to pass line/patch
instances and use introspection to automagically determine the colors.
It would simplify your life if you just provided helper methods like
 set_row_facecolor(colorarg, i)
 set_row_edgecolor(colorarg, i)
 set_col_facecolor(colorarg, j)
 set_col_edgecolor(colorarg, j)
 set_cell_edgecolor(colorarg, i, j) and so on
Let the user build the table. We can supply a helper function to
automatically build tables from stacked bar charts using
introspection, but I think from a design standpoint you will make your
life a lot easier by separating out this functionality.
JDH

Hi John,
I've moved on a fair bit with this, still quite a way to go.
I'm attaching some new files and patches which will make it easier for
me to explain where i am at with all this.
table.py is my hacked version of legend.py that does tables.
axes.patch is a patch to axes.py that adds table support.
table_demo.py and table_demo2.py are a couple of demos of what I've got
so far.
table_demo.py shows tables being places all over the place.
table_demo2.py shows the sort of thing I'm really after.
The basic idea with table is that it allows you to create a table which
can be placed either inside the axes (as per legend), or outside the
axes. This is controlled by the loc arguement.
Each cell in a table can have an optional handle as per legend and some
text.
Currently you have to specify the column widths for the table. Really
two cases should be supported: allow the user to specify the widths
(this is needed so you can line up tables with bar plots) and allow the
Table to auto-adjust the widths to make everything just big enough for
whatever text is present (this is handy for legend type stuff). I've
done nothing for auto-guessing of widths as yet.
I've made the grid within the tables an option + I think with a little
more work legend.py could just use table.py to do what it has to do.
There is an ugly hack, rowOffset that I use in table_demo2.py to get the
row labels to align with the appropriate data. My idea was that it
might be simpler to have a basic table object and then build up more
complicated stuff such as including row-labels by creating multiple
tables. 
Currently I can't decide whether i wouldn't be better trying to support
the row/column labels all in the one object -- I suspect this is the way
to go since it is easier to get things to line up this way rather than
trying to align lots of separate tables (eg if i start supporting
different fonts for different tables then we'll really be in trouble).
Now as I said there is still lots to do here. 
There are all sorts of minor and not so minor alignment issues to
address -- a lot of these I think I can solve by paying a bit more
attention to the legend.py code.
The most significant problem at the moment is that the tables are
getting clipped -- I'm not sure how I control the size of the border
around the axes.
I'd also like to make it so you can specify that text should be
left/right/centre aligned.
There is also quite a bit of work to do on the actual interface to the
table objects, basically making them smart about the parameters they are
given so that simple cases just work by magic. They are in danger of
sprouting a plethora of options + no-one will be able to figure out how
to use the things. 
Anyway, so far it has been fun working with this stuff.
John

>>>>> "John" == John Gill <jn...@eu...> writes:
 John> I was hoping I could do things like specify negative
 John> y-positions to draw below the axes, but I now think I'm
 John> deluded in thinking this 'cos matplotlib is smart and every
 John> time something gets drawn the axes are automagically
 John> adjusted to make sure the latest lines/rectangles are
 John> included.
If this is the case it appears to me that you are using the
axes.add_line command, no? That is where matplotlib does the
autoscale view limits thingie. There is nothing in the architecture
that prevents you from drawing outside the axes view limits, except
for clipping, which you can set.
I think you should have a Table class which is contained by the axes.
The Table should derive from an Artist and implement the required
_draw method, which is called with a renderer instance. This method
should forward the draw call to all the text, lines and patches
contained by the table, just as legend does.
class Table
 def _draw(self, renderer):
 for line in self._lines: line.draw(renderer)
 for t in self._texts: t.draw(renderer)
This is how Legend does it. If you set it up this way, the axes
instances won't know anything about the line instances and you can
definitely draw outside the axes bbox. If not, matplotlib.axes has
achieved consciousness and we are no longer in control <wink>. Note
that it is critical that you make the call
 self.line1.set_clip_on(False)
to allow drawing outside the axes bbox.
Here's an example table class that you can use to draw inside or
outside the axes bbox. Note there is no reason we can't do this at
the figure level, but the advantage of doing it at the axes level is
that you may want some of the lines to be in data coords, eg, the
vertical lines lining up with the xticks in the example you showed me.
It might be worth taking some time to figure out how to have figure
tables or axes tables, eg with a base class and 2 derived classes, but
for now focus on the axes table and we can generalize once you have
the nuances worked out.
class Table(Artist):
 def __init__(self, axes):
 Artist.__init__(self, axes.dpi, axes.bbox)
 self.axes = axes
 left = 0.9
 right = 1.2
 bottom = 0.9
 top = 1.5
 
 self.line1 = Line2D(
 axes.dpi, axes.bbox,
 (left, left), (bottom, top),
 transx=self.axes.xaxis.transAxis,
 transy=self.axes.yaxis.transAxis
 )
 self.line1.set_clip_on(False)
 def _draw(self, renderer):
 self.line1.draw(renderer)
You can add an add_table method to Axes, and define a list of 
 class Axes(Artis):
 def __init__(self, blah, blah):
 # ..snip the other Axes init stuff
 self._tables = [] 
 def add_table(self, table):
 self._tables.append(table)
 def _draw(self, renderer):
 # ..snip the other draw calls
 for table in self._tables:
 table.draw(renderer)
I tested my code above with this scheme and it works - it drew a
vertical blue line from inside the axes to outside.
If you have any more troubles send me some code and I'll take a look.
JDH

I've spent some more time working on the idea of using a common image
renderer for the GUIs. As I mentioned before, this will remain
optional so no need to be concerned about losing support for the
current GTK or WX backend, but this will enable us to add capabilities
to the GUI backends that they may not natively support.
I've been working on the GTKGD backend as a testbed since we already
have the GUI architecture in GTK and the drawing architecture in GD.
This already backend provides additional capabilities to GTK, namely
antialiased lines and arbitrary text rotation. I wrote some C code to
transfer the image from GD->GTK so it is now fast enough to be usable,
though not as fast as the native GTK solution. There are some
performance bottlenecks in GD that I've identified in the profiler so
the current speed can be improved.
David Moore has implemented a paint backend (a libart wrapper).
libart is a sophisticated render engine that is currently used as the
renderer for Gnome Canvas and is ported to all the major platforms.
Although he is waiting on some paint patches he applied to be
incorporated, this provides another candidate backend for a common
image renderer.
I've updated CVS. In setup.py there is a line 'if 0' that needs to be
replaced with 'if 1' to compile the extension module (does anybody
know how to set flags for distutils?) The GTKGD backend now passes
all the regression tests (though there is a color allocation but that
seems to be a gdmodule problem) and serves as a template for GUI
implementers who want to get something up and running fast. With this
approach, the backend writer does not need to implement either a
Renderer or a GraphicsContext. Once you have the GUI architecture
setup, adding a different image renderer is as simple as doing a
importing a different FigureCanvasBackend and writing an image->gui
canvas transfer function.
If there are any brave souls who want to test this out and working,
I'd be much obliged. You'll need the requirements for the GTK and GD
backends installed as described on
http://matplotlib.sourceforge.net/backends.html, including the
gdmodule patch. Let me know if you encounter any compile problems.
JDH

John,
Thanks for the hints.
First I've tried subscribing to the devel list -- sourceforge is sulking
again, so no joy so far, i've cc'ed the list on this, so if it accepts
posts from non-subcribees it should get there.
I've looked a bit at the transforms stuff + things are making a bit more
sense, but I'm still unable to achieve what I'd like.
I think the basic problem is that Line2D and Rectangle are intended to
draw on the axes, whereas what I'd ideally like to do is draw outside
the axes (see the screenshot i sent originally) -- ie instead of doing
what is done with the legend and have it appear somewhere within the
axes of the plot I'd like the table of data to be outside this.
I was hoping I could do things like specify negative y-positions to draw
below the axes, but I now think I'm deluded in thinking this 'cos
matplotlib is smart and every time something gets drawn the axes are
automagically adjusted to make sure the latest lines/rectangles are
included.
I suspect I need some new sort of object to draw outside the axes - can
you confirm that is the case?
Plan B. would be to just live with putting the tables within the plot,
as per the legend, but this doesn't work too well in general 'cos the
table tends to obscure some important part of the plot.
Let me know if this is still hard to understand and I'll try and get
what I have into a state which demonstrates the problem I am running
into.
John

>>>>> "John" == John Gill <jn...@eu...> writes:
Hi John, could you also subscribe to matplotlib-devel and CC the
messages to me (matplotlib-devel sometimes has a long lag). It would
be nice to have these discussions there for archival purposes and so
that others can offer suggestions. Hopefully, you'll have an easier
time getting sighed up there than you did on matplotlib-users.
 John> John, First the good news. I've had a good read of
 John> legend.py and now pretty much understand how it is working.
Excellent, between the 2 of us, that makes at least one person who
understands that code <wink>.
 John> Now the bad news. The way I'm thinking about these tables
 John> is that I will want to draw them below the main plot area,
 John> sort of where the xticklabels go at the moment + the area
 John> below.
But you should try and code it generally so people can place them
wherever they want right? Perhaps you should construct the table with
a list of horizontal lines and a list of vertical lines and their
respective transforms (see below). Or are you already doing this?
 John> Now I tried hacking about a table.py copy of legend.py and
 John> drawing a grid of lines in this area -- the code runs fine
 John> but I don't get a nice grid of lines :( (see snippet of code
 John> below).
 John> If I cheat and arrange for the drawing to take place within
 John> the main plot (by carefully fixing the ypos stuff below)
 John> then things work fine.
 John> I'm guessing I need to do something to let matplotlib know
 John> the extent of what I'm drawing, but I am at a loss as to
 John> what that something is.
 John> Can you point me in the right direction?
Without a complete code example, I can only guess. My guess is that
you are using the wrong transforms. Each axis instance has a
transAxis and a transData attribute you can use. When you want to
specify a coordinate in axis units (0,1), use the transAxis instance.
If you want to specify a coordinate in data units, use transData.
Eg, if you want the vertical lines (x coords) of your table to line up
with the xticks and the horizontal lines (y coords) of your table to
be in axis units (eg 10% of the axis apart), you would initialize your
line like
 ypos = 0.1 # 10% of axes height
 line = Line2D( self.dpi, self.bbox,
 xdata=(xpos, xpos), ydata=(0, ypos),
 color='k', linestyle=':',
 transx = self.axes.xaxis.transData,
 transy = self.axes.yaxis.transAxis,
 )
Make sure you turn clipping off (it appears you did for your
examples), particularly while developing.
 John> (aside: it did occur to me that one way i could cheat an
 John> nearly get what i want is to use the bar() method to draw my
 John> grid + then use the text() method to enter all the text I
 John> want in the grid...)
Cheating is usually a bad thing. I think you'll need to construct
your own text instances with the same x and y transforms you use for
your lines, eg, x coordinate in data units and y coordinate in axis
units. This will also encapsulate the table as a single instance which
will make it easier to manipulate; eg to set text properties for the
entire table.
Hope this helps, if not send me a complete example with demo script
and I can take a closer look.
JDH