yet another fancy arrow, etc

Development matplotlib-devel
1

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

arrow.jpg

2

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.

···

On Tue, Sep 23, 2008 at 3:22 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

3

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

4

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