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? 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. * 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). My inclination is to go with the first option. But since this seems a bit hackish way to do it, I want to know how others think. Any comment, suggestion, or advice would be appreciated. -JJ
On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <lee...@gm...> 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.
> > 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. > > Thanks. Yes, merging seems better to me too. And it seems that I can slightly tweak the current interface of my class so that it get along well with pre-existing classes. I'll work on the merge and post the patch sometime soon. > > 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.... > I'm not sure if scanline_boolean does what I want (but I have to admit that I haven't looked at its code carefully yet). Do you know if it is possible to stroke along the union of the two paths (this is what I want)? My impression is that scanline thing is for filling the path. Anyhow, I'll take a more look. > > This appears to be LGPL, so we will not be using it in the main distro. > Yes, it's LGPL. And I didn't mean to include it in mpl. Anyhow, I think I'll go with the first method for the moment. Thanks, -JJ
Jae-Joon Lee wrote: >> 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.... >> >> > > I'm not sure if scanline_boolean does what I want (but I have to admit > that I haven't looked at its code carefully yet). Do you know if it is > possible to stroke along the union of the two paths (this is what I > want)? My impression is that scanline thing is for filling the path. > Anyhow, I'll take a more look. > You should probably be able to take the union of two stroked paths -- which is not a geometry package like lib2geom would do, but it should be good enough/fast enough. Of course, any solution will have to work with all backends, not just Agg. > >> This appears to be LGPL, so we will not be using it in the main distro. >> >> > > Yes, it's LGPL. > And I didn't mean to include it in mpl. > Anyhow, I think I'll go with the first method for the moment. > It sounds like this method should also be the most portable between backends. I doubt efficiency is a concern, because there's a real upper limit on the number of these annotations before things become illegible. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
,){kind=link}