matplotlib-devel Mailing List for matplotlib

>>>>> "Jack" == Jack Diederich <jac...@ja...> writes:
 Jack> Hi, I just subscribed to the list and have been looking at
 Jack> the source. I wrote a python graphing library so lots of
 Jack> the internals are familair (how many ways can you draw a
 Jack> line?) but spending a couple hours browsing the code I can't
 Jack> get a handle on how layout is done. Are things generally at
 Jack> fixed positions? Are there some things I can
 Jack> subclass/decorate to get a different look or feel?
Yes, things are placed in fixed positions. Fixed here can mean
relative to something else, as in 20% from the left side of the axes,
but not free in the sense of a layout engine that tries to find
optimal placement.
For example, you can place axes with
 axes([left, bottom, width, height]) 
and these are expressed in fractions of the figure width and height.
Eg, http://matplotlib.sourceforge.net/screenshots.html#axes_demo. Or
you can place a rectangle in relative axes coords (0,0) bottom left,
(1,1) top right with a custom transform
 Rectangle( xy=(0.25, 0.5), width=0.1, height=0.2,
 transform=ax.transAxes)
There has been a lot of clamoring for a layout engine, particularly
because when you have a number of subplots, the text labels from one
axes can overlap another as discussed here -
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP . In order to
incorporate a layout engine, you would need at a minimum to subclass
Figure and Axes. Most of the scene objects (matplotlib.artist.Artist)
can return their bounding box in window extent, and you could use this
information to help with layout. The transforms module has a helper
function bbox_all which takes a sequence of bounding boxes
(transform.Bbox instances) and returns the box that bounds them all --
very useful when doing layout. Basically, the Figure would want to
inspect it's axes and the axes in turn would inspect the bounding
boxes of the objects in contains.
The only catch is that in the current implementation, text instances
do not know their window extent until drawing time. This is because
text sizes are backend dependent, and the class that knows how to size
text is the backend Renderer, which isn't known to the objects until
the call to Artist.draw(renderer). This has proved to be a pain in
the ass since in some classes (eg legend, ticks, tables and text
itself) which need to do some layout involving text, the layout is
deferred until drawing time and then the information is sometimes
cached for efficiency. Typically this leads to hairy, suboptimal, and
hard-to-maintain code, cf Legend._update_positions and
Text._get_layout.
One potential way out of this dilemma is to use the ft2font module
(matplotlib's freetype2 wrapper) to get the layout information
whenever you want it. matplotlib's core backend agg uses this anyhow,
and postscript embeds freetype2 fonts and so uses it too. It remains
to be seen how well this strategy would work on the SVG and Cairo
backends, which are the only other two renderers are actively
supported and used, as far as I know. I know Steve has taken some
pains to get Cairo text sizing similar to Aggs/GTKs, so it may serve
as a good enough approximation for layout purposes for cairo as well.
We've been trying to push GD users -> Agg, and users who use native
GTK/WX drawing to GTKAgg/WXAgg, because this simplifies maintenance.
 Jack> I had a longstanding misimpression that matplotlib was a
 Jack> wrapper around matlab or I might have abandoned my custom
You're not the first to have this misperception. I wonder how we can
combat it. Perhaps renaming the main interface pylab will help. Or a
blinking box on the homepage maybe - "matplotlib does not require
matlab! That's the whole point!!'" :-)
 Jack> work and just thrown in here. If I can get graphs that look
 Jack> like this[1] I'll do just that.
We'd love to have you on board - then we'd be collaborating on two
projects :-)
 Jack> Sorry for the vague questions, but I'll try to recompense by
 Jack> porting my PIL and ming backends over Christmas. The
 Jack> unmodified backends are stupid similar to matplotlib (again,
 Jack> there aren't too many ways to spell 'line')
Right, the backends are dumb as bricks by design, because this lowers
the barrier of entry in writing a new backend. Actually, they're too
dumb currently, because the frontend handles the transformation to
display coordinates, which isn't optimal for backends that have
transformations built in (eg PS, SVG) and leads to some problems with
subpixel antialiasing in agg. Fixing this is on the list of things to
do.
 Jack> Ignore the "shape_*" methods, they just return a handle to
 Jack> paintable objects instead of doing the paint right away
 Jack> (required for doing hovers and sprites in ming/Flash).
As I mentioned to you earlier, I think the hover capabilities of
ming/Flash would be very appealing to webapp developers. Actually, I
think these are great for all domains, because they let you pack so
much information into a figure. Could this be embedded in a GUI,
bychance? 
I've been meaning to make some alterations in the frontend to support
clickable elements, eg in SVG, and this wouldn't be hard. The same
framework could be used for tagging hover elements. If you want to
take the lead here, by all means. Otherwise, when you get to this
point let me know and I can work with you on it.
 Jack> [1] I only need a few kinds of graphs but they are for
 Jack> marketing folks instead of tech folks so purtier is better.
 Jack> I put up some samples of our current output here (png &
 Jack> Flash) http://jackdied.com/jackdied/graph_sample.html
Everything except the 3D bar look is already supported. We have major
and minor ticking, solid date support, legends, bar and line charts.
I'm personally not too interested in 3D bars because I don't think the
3D effect adds any information and arguably reduces it. I would not
oppose a patch, though. It would be fairly trivial to write, I
suspect.
See examples/major_minor_demo*.py, examples/date_demo*.py
examples/barchart_demo.py and examples/legend_demo*.py in the src
distro.
A few brief notes:
 - you can set the figure background color with the figure command
 and customize the default in the rc file
 - you can customize the default grid style (eg a solid gray line)
 using the rc file, the rc command, or directly setting the line
 properties on the result of, eg, ax.get_xgridlines()
 
 lines = ax.get_xgridlines() + ax.get_ygridlines()
 set(lines, linestyle='-', color='lightslategray', linewidth=1)
 
 - You have a "bar" and a "plot" overlayed. Just make sure hold is
 set to True so that subsequent plots don't overwrite old plots.
 You can set the default state in rc, toggle it with the "hold
 command" or pass hold as a kwarg on a given plot command to
 temporarily override the hold state
 - To offset the major ticks ('Nov', 'Dec') below the minor ticks,
 you may want to simply prepend them with a newline ('\nNov',
 '\nDec'). You'll want to use custom date tick formatters as
 illustrated in the date demo files referenced above. There are a
 number of other ways to control the vertical offset (see also the
 verticalalignment of the text instances) but the newline trick may
 be enough to get them into the position you want.
 - The legend doesn't have a shadow feature built in, though you
 could add one trivially and I would be happy to accept a patch. 
 This could be a general feature of patches, actually.
 JDH

Hi, I just subscribed to the list and have been looking at the source.
I wrote a python graphing library so lots of the internals are familair
(how many ways can you draw a line?) but spending a couple hours browsing
the code I can't get a handle on how layout is done. Are things generally
at fixed positions? Are there some things I can subclass/decorate to get
a different look or feel?
I had a longstanding misimpression that matplotlib was a wrapper around
matlab or I might have abandoned my custom work and just thrown in here.
If I can get graphs that look like this[1] I'll do just that.
Sorry for the vague questions, but I'll try to recompense by porting my PIL 
and ming backends over Christmas. The unmodified backends are stupid similar
to matplotlib (again, there aren't too many ways to spell 'line')
Python 2.3.4 (#2, Dec 3 2004, 13:53:17) 
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import Graph
>>> filter(lambda x:'__' not in x, dir(Graph.mingDraw))
['circle', 'clip', 'color', 'color_from_tup', 'line', 'pieslice', 'polygon', 
 'rectangle', 'shape_circle', 'shape_line', 'shape_pieslice', 
 'shape_rectangle', 'text', 'tup_from_color', 'write']
Ignore the "shape_*" methods, they just return a handle to paintable objects
instead of doing the paint right away (required for doing hovers and sprites
in ming/Flash).
-Jack
[1] I only need a few kinds of graphs but they are for marketing folks
 instead of tech folks so purtier is better. I put up some samples of
 our current output here (png & Flash)
 http://jackdied.com/jackdied/graph_sample.html