man, that commit message is embarrassing ...

I suspect something subtle got broken when annotations changed from a 'has-a' to 'is-a' Text object.

My guess is that something changed about where the base of the arrow is calculated and poor interaction with the FancyArrowPatch object that gets created.

I am some what more distressed by the extra blue lines around the vertical blue dashed lines.

in _update_positoin_xytext there are a bunch of calls to get_window_extent which is where I suspect the issue is (as the reported extent of the annotation object may have changed.

(mostly notes to my self)

"something changed about where the base of the arrow is calculated"

This sounds familiar. I think we fixed a real bug wrt how the arrow was
positioned awhile back.

On Mon, Jan 19, 2015 at 11:49 AM, Thomas A Caswell <[email protected]

wrote:

I suspect something subtle got broken when annotations changed from a
'has-a' to 'is-a' Text object.

My guess is that something changed about where the base of the arrow is
calculated and poor interaction with the FancyArrowPatch object that gets
created.

I am some what more distressed by the extra blue lines around the vertical
blue dashed lines.

—
Reply to this email directly or view it on GitHub
#4012 (comment)
.

@WeatherGod How recently?

Perhaps this (or one of the ones referenced in it)?
#566
But, for some reason, I am thinking of something more recently (like, a bug
fixed for 1.3.x)

On Mon, Jan 19, 2015 at 2:57 PM, Thomas A Caswell [email protected]
wrote:

@WeatherGod https://github.com/WeatherGod How recently?

—
Reply to this email directly or view it on GitHub
#4012 (comment)
.

For a simpler example, I took the annotation_demo.py example and changed the arrowprops to match the one in ObsPy.

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.patches import Ellipse


fig = plt.figure()
ax = fig.add_subplot(111, autoscale_on=False, xlim=(-1,5), ylim=(-3,5))

t = np.arange(0.0, 5.0, 0.01)
s = np.cos(2 * np.pi * t)
ax.plot(t, s, lw=3, color='purple')

arrowprops = dict(arrowstyle="wedge,tail_width=1.4,shrink_factor=0.8")

ax.annotate('axes center', xy=(.5, .5),  xycoords='axes fraction',
            horizontalalignment='center', verticalalignment='center',
            arrowprops=arrowprops)

ax.annotate('pixels', xy=(20, 20),  xycoords='figure pixels',
            arrowprops=arrowprops)

ax.annotate('points', xy=(100, 300),  xycoords='figure points',
            arrowprops=arrowprops)

ax.annotate('offset', xy=(1, 1),  xycoords='data',
            xytext=(-15, 10), textcoords='offset points',
            horizontalalignment='right', verticalalignment='bottom',
            arrowprops=arrowprops)

ax.annotate('local max', xy=(3, 1),  xycoords='data',
            xytext=(0.8, 0.95), textcoords='axes fraction',
            horizontalalignment='right', verticalalignment='top',
            arrowprops=arrowprops)

ax.annotate('a fractional title', xy=(.025, .975),
            xycoords='figure fraction',
            horizontalalignment='left', verticalalignment='top',
            fontsize=20,
            arrowprops=arrowprops)

ax.annotate('bottom right (points)', xy=(-10, 10),
            xycoords='axes points',
            horizontalalignment='right', verticalalignment='bottom',
            fontsize=20,
            arrowprops=arrowprops)

plt.show()

Here is 1.3.1:

Here is 1.4.2:

And the diff:

I'm not sure if this adequately replicates the above issue, but it does point to xycoords='axes points' being broken in some way.

I am some what more distressed by the extra blue lines around the vertical blue dashed lines.

Yea, that's odd too. I will try to see where those lines originate.

I am some what more distressed by the extra blue lines around the vertical blue dashed lines.

Yea, that's odd too. I will try to see where those lines originate.

I honestly don't know where these are from, and they stopped showing up, so I wouldn't worry about them.

this seems to be fixed by #4019

I'm sorry, it seems that simple example exposes a different bug. Here is a test case that should only trigger the bug in the first post:

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.transforms import blended_transform_factory

fig = plt.figure()
ax = fig.add_subplot(111, autoscale_on=False, xlim=(-1,5), ylim=(-3,5))

t = np.arange(0.0, 5.0, 0.01)
s = np.cos(2 * np.pi * t)
ax.plot(t, s, lw=3, color='purple')

trans_above = blended_transform_factory(ax.transData,
                                        ax.transAxes)
trans_right = blended_transform_factory(ax.transAxes,
                                        ax.transData)

bbox = dict(boxstyle="round", fc="w")

arrowprops = dict(arrowstyle="wedge,tail_width=1.4,shrink_factor=0.8")

ax.annotate("0.1",
            (3, 1.0),
            xytext=(3, 1.1),
            xycoords=trans_above, textcoords=trans_above,
            ha="center", va="bottom",
            arrowprops=arrowprops, bbox=bbox)

ax.annotate("0.2",
            (1.0, 0.75),
            xytext=(1.05, 0.75),
            xycoords=trans_right, textcoords=trans_right,
            ha="left", va="center",
            arrowprops=arrowprops, bbox=bbox)

plt.show()

With 1.3.1:

and with 1.4.2:

Diff:

If you remove the bbox, they work the same.

Digging into this I still have no idea what the problem is. My suspicion is that something I changed had a crucial side effect...

I am going to take one more pass at this tomorrow, if I can't figure it out I am going to boot this to 1.4.x as this seems to be only an issue when using both the FancyArrowPatch and FancyBoundingBox at the same time.

attn @leejjoon Can you point me in the right direction on this? I think something in getting out of sync in updating where the center of the text is with the bounding box.

@QuLogic Can you check your examples with current master, I think #4178 fixes part of the issues.

It's pretty close now. There's a slight difference in the box, but that may be due to font changes (the tick labels have also shifted a little)?

I am more concerned about the shift in the plotted line. Did you make the diff from my png, or from running it on your system?

From running it on my system, using the original mpl131.png I generated a while back for reference (which is byte-for-byte the same as the one here, it seems.)

On 2015/07/22 10:47 AM, Thomas A Caswell wrote:

I am more concerned about the shift in the plotted line.

That looks to me like a difference in rendered width, not in position.

If you're really interested in the shift, the bisect was inconclusive:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
4a56cda
cfbf8d5
339537d
8dae818
6e19dac
a225968
697b3ef
c5ab747
5204635
af578f5
0624664
6d07179
ba40160
d862c47
d8c1d0d
We cannot bisect more!
bisect run cannot continue any more

@QuLogic That is inside of the massive re-work of how we expose Agg up to python.

We have also done some changes to how white space around fonts is handled.

@mdboom I am inclined to call this good enough?

Closing this as 'good enough'.

@QuLogic Please ping to have this re-opened if you disagree.