Thanks for the detailed bug report! Could you narrow down some example values of x1, x2, y1, y2 where the arrow is drawn incorrectly?

When I looked at this a bit more deeply, I realized that the arrows are drawn completely wrong. The starting points are correct, but the ends points are all messed up. I thought this had something to do with "shrink" arguments, yet they are all zero and I do not completely understand why do they in any way affect the coordinate-wise positions of the arrows. If this is expected behavior, I would like to know the correct way to handle things so that it behaves as any other matplotlib artist behaves.

from matplotlib.collections import PatchCollection
import numpy as np
from matplotlib import pyplot as plt
from matplotlib.patches import FancyArrowPatch

plt.figure(figsize=(40,20))
ax = plt.gca()

arrows = np.array([
    [48.0, 71.0, 49.57329806959083, 69.0], 
    [48.0, 77.0, 49.79262616791978, 75.0], 
    [48.0, 83.0, 50.39460028345314, 81.0], 
    [48.0, 89.0, 52.0, 87.0], 
    [48.0, 95.0, 52.0, 93.0]
])

arrow_patches=[]
for x1, y1, x2, y2 in arrows:
    arrow_patches.append(
        FancyArrowPatch(
            (x1, y1),
            (x2, y2),
            linewidth=3,
            color="red",
            shrinkA=0,
            shrinkB=0,
            arrowstyle="-|>, head_length=0.3, head_width=0.3"
        )
    )
arrow_collection = PatchCollection(arrow_patches, zorder=1, match_original=True)
ax.set_xlim(47,51)
ax.set_ylim(70,96)
ax.add_collection(arrow_collection)

Okay, found it I think. It is the linewidth argument that messes things up here. I really did not suspect that, it is weird. Is this expected? Should we not touch lw while playing with arrows? Then how will we determine the width for fancyarrowpatch?

FancyArrowPatch(
    (x1, y1),
    (x2, y2),
    color="red",
    shrinkA=0,
    shrinkB=0,
    arrowstyle="-|>, head_length=0.3, head_width=0.3"
)

EDIT: As a final addition, removing both the linewidth and shrink arguments (i.e. defaulting them) also produces this error.

FancyArrowPatch(
    (x1, y1),
    (x2, y2),
    color="red",
    arrowstyle="-|>, head_length=0.3, head_width=0.3"
)

Found the culprit. In this line, a padding is calculated for the projected edge, that basically forces the arrow wedge to be placed in somewhere it should not be. For shrinkA=0 and shrinkB=0, there shouldn't even be such a parameter (though I do not understand why there are shrink arguments either). Setting it to zero (i.e. pad_projected = 0) produces the expected arrows for me, with Matplotlib version: 3.3.3.

I checked out the blame and this line was added more than ten years ago, so I cannot flag anyone to explain what this was supposed to be doing. If this is for clipping purposes to remedy the "projecting" capstyle, maybe a clip_path can be added instead, as in patch.set_clip_path(patch), thus effectively removing the overflowing edges from the lines drawn (I have used this approach many times before and it is quite effective). A lot of improvements have happened in the last 10 years, and looking at the comment above the line, I doubt this approach is necessary anymore.

@dstansby if the main contributors of matplotlib can agree on a way to go, I can implement the changes. Or, I can just delve into it and create a PR, and see what happens.

EDIT: I think I understand what the line is supposed to be doing and how it fails: .5*linewidth is indeed the overflown edge to be accounted for, as in the half of the edge that resides in the wrong part of the path. However, that linewidth is in point units while the rest of the values are in the coordinates of the axes (possibly cartesian), so it does not actually do anything, and the issue appears only when the scale is small enough for it to be visible.

And here are the more "fun" parts: The default capstyle for arrow patch is not even "projecting" (also see #13647). On top of that, I think the authors of the function was pointing to "joinstyle" rather than "capstyle" (or maybe this change is younger than 10 years?) since the arrow head is a closed path, so there are no "caps" and the arrow head location cannot be affected by capstyle.

So much weird stuff is going on here. Maybe just rewrite everything related to arrows?

My recollection is vague, but here are what I remembers.

FancyArrowPatch was originally designed for annotations. So some of the parameters are introduced and have default values so that we have more visually pleasing annotation (at least that was my intention 10 years ago). For example, the example below may explain why we needed a shrink parameter.

https://matplotlib.org/gallery/userdemo/annotate_explain.html#sphx-glr-gallery-userdemo-annotate-explain-py

Also, as it was mainly meant to be used in "points" coordinate (since that is what annotate uses to draw arrows), some of the code may not correctly work if the coordinate is different.

I guess pad_projected (it should have been pad_miter as you pointed out) was introduced to prevent the arrow overflowing into the annotated patch independently of its linewidth (maybe "miter" was default joinstyle for arrows at that time?). Clipping is different here as you will loose sharp arrow tips.

Surely, the code need improvements. pad_projected could behave differently based on joinstyles, and an option to turn that behavior off could also be desirable. We may need to revisit its default behavior. Also, it should account for the coordinate correctly.

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!