Hi,
Well, I now know more than I ever wanted to about clabel. I decided to
improve a bit on the inlining and ended up rewriting it. For automatic
label placement, I basically use the existing algorithm for determining
label location, but have replaced existing code for determining the
angle of rotation and the amount of the contour to take off for inlining
with new code. This new code is based on using pixel-space distances
along the contour. This allows one to (1) get nice balanced inlining
with the same amount of space on either side of the label, and (2) to
vary the amount of space you want around the label. It also should deal
better with labels located near contour edges and labels covering the
entire contour.
Along the way, I renamed all ContourLabeler specific attributes to
something like .labelAttribute. This makes the namespace cleaner in my
mind, but might break existing user code that does things directly with
ContourLabeler attributes.
I also added a few new functions to cbook. One does simple linear
interpolation (in addition to an existing cbook function that is similar
but a bit different). Others do things with vector lengths. I also
added a function called isvector that is identical to a Matlab function
of the same name. If desired, I can move this to mlab.py, but for the
moment it is in cbook.py because most of the is? functions are there.
On an aside, I noted that mlab.norm uses cut-and-paste documentation
from Matlab. Is this wise?
I have tested all the changes against the existing pylab_examples and
things work fine. Nonetheless, since lots of things have been changed,
I haven't committed them for fear of interfering with the release.
Instead, I am attaching the patch set. If I get the green light, I will
commit these changes.
Related: while I am digging around in there, now is probably the moment
for me to integrate Paul Kienzle's comments on start/stop_event_loop in
FigureCanvasBase, etc. I am not sure there is a consensus on this. I
am currently thinking that the best way to integrate this, while
minimizing repeated code, is a mixin plus a couple of new classes,
FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would
inherit the mixin and the base classes without "GUI". Interactive
backends would then inherit these. Non-interactive backends would
inherit versions that throw errors from FigureBaseCanvas. Complex, but
this assures clean inheritance. Thoughts welcome.
Cheers,
David
clabel_rewrite.patch (27.5 KB)
···
--
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************