plt.annotate() FancyArrowPatch does not respect patchA, patchB clipping

[mpharrigan]

• python 3.5, matplotlib 1.5.1
• from miniconda (latest)

Sample code (sorry it's long, but it is self contained). Please look at where I use patchA and patchB with my arrow props in annotate

from matplotlib import pyplot as plt
import itertools

patches = {}
positions = {
        'box 1': [0,0],
        'box 2': [1,0],
        'box 3': [0,1],
}

# Points
for st, (x,y) in positions.items():
    patches[st] = plt.text(x, y, st,
         ha='center', va='center',
         size= 20,
         bbox={'alpha': 0.8},
    )

# Arrows
for r, c in itertools.product(positions.keys(), positions.keys()):
    if r == c:
        continue # skip self-connections

    # Draw arrows
    x1 = positions[c]
    x2 = positions[r]
    plt.annotate('', x2, xytext=x1,
                 arrowprops=dict(
                    arrowstyle='->',
                    connectionstyle='arc3,rad=.2',
                    # THIS IS THE IMPORTANT PART vvv
                    patchA=patches[c],
                    patchB=patches[r],
                    # ^^^^^^^^^^
                 ),
                 zorder=-1,
    )

plt.xlim((-0.5,1.5))
plt.ylim(-0.5, 1.5)
plt.savefig("plot.pdf")
plt.savefig("plot.png")

png

pdf

I expect the arrows to be "clipped" by the boxes at the start and end of each arrow. The pdf (and svg) exported version doesn't clip at all. The png version does something weird.

I also tried the "cairo" backend. It also performs no clipping [but changes the bend of the arrows]. Interestingly, the only thing that seems to work is the %matplotlib inline ipython notebook backend. It renders a png exactly as I would expect.

[tacaswell]

It is odd that %inline works, but just saving does not as it is going through the same code path.

This makes me think that this is a DPI related bug and in probably related to #6054

[tacaswell]

Interactively it looks ok, then I save it and I get the same strange arrows

if you set the figure dpi to 100 and saving gives the correct result (but temporarily get the same funny issue in the interactive window.

If you make sure the z-order of the arrows is above that of the patches it also seems to work (here -40 for the text, 1 for the arrows.

so.pdf

[mpharrigan]

wow, thanks for looking into this. Seems like I have at least one workaround now :)

[tacaswell]

tl;dr

The problem seems to be draw order related. The root of the problem is that we do not know how big the text will be until it is drawn, but in order for the fancy arrow back off to work (end at the edge of the bounding box, not at the center of the text) they need to know how big the text is. The draw process is a single pass operation (unless you use tight_layout or bounding_box_inches='tight' where it gets rendered twice which is probably why %inline worked). Aritsts are drawn in increasing z-order and there is no clean internal way to express 'I depend on that other artist being drawn first'.

The two workarounds are:

1. adjust the z-order so the text is always rendered firs
2. make sure you call save twice 😉

[mpharrigan]

changing the z-order fixed it. calling save twice seems to shrink the arrows too much (when using shrinkA and shrinkB) in pdf output

[github-actions]

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!