On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Hello, > > I'm working on the fancy annotation thing I mentioned the other day, > and I want to have some feedback and advice. > > As you see (http://dl.getdropbox.com/u/178748/test_fancy_annotation.jpg), > the annotation will be consist of a fancy box + fancy arrow. And my > current plan is to put the fancy arrow things as an arrow patch class > in the patches.py. The new class would be very similar to the > FancyBboxPatch class. It will take three control points of quadratic > bezier path as an input, and will draw an arrow around this path (an > example is attached). For example > > mypatch = YAFancyArrowPatch([(cx0, cy0), (cx1, cy1), (cx2, cy2)], > arrowstyle="simple", > ec="blue!50!white", > fc="blue!20!white") > > But, patches.py already has three arrow classes. > > * Arrow(x, y, dx, dy) > * FancyArrow(x, y, dx, dy) > * YAArrow(figure, xytip, xybase) > > And I'm a bit hesitating in adding yet another arrow class. One way > I'm considering is to merge my arrow class with the currently existing > FancyArrow class (or other). But their interface is a bit different > and I'm afraid that it may confuse users. So, how others think? Would > it better to simply have a seperate arrow class or to have it merged > into one of the existing arrow classes?
Well merging is obviously better. I wrote YAArrow to support plain-vanilla annotations. AFAIK, they are used nowhere else, so as long as we could come up with one arrow class that works with plain-vanilla and fancy annotations, that would be good. But it may be easier said than done. These annotation arrows are really helper classes that are instantiated by higher level functions (eg users most likely won't be creating them themselves) and since they all have the basic patch interface, I don't think having a proliferation of them is the worst thing in the world, though the ideal is to have as few classes as possible that serve as many cases as possible. > The other thing is, as I said, the annotation is consist of a fancy > box and fancy arrow, which means we need to draw a union of two closed > bezier path. I hoped that the agg package have those kind > functionality but I couldn't find one (if there is, please let me > know). So, I think there are two options. I believe you are looking for the scanline boolean algebra -- search the antigrain demo page http://www.antigrain.com/demo/index.html for scanline_boolean.cpp. Of course, we would need to support the other major backends too.... > * Forget the union operation and fake it by modifying the order of > "stroke" and "fill", i.e, stroke the paths of the box and arrow first > then fill each path later (with a same color). The above figure uses > this approach. It would not work if your want a transparent fill > color. > > * Or, use an external library. > 2geom(http://lib2geom.sourceforge.net/) seems promising, and I > currently have a simple wrapper based on it which does the job (2geom > does provide a python interface but not all of its funtionality are > wrapped yet. So I needed make a few changes). This appears to be LGPL, so we will not be using it in the main distro. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
