I am trying to write an image comparison test for label_lines, here is my progress:

@image_comparison(['label_lines'])
def test_label_lines():
    plt.rcParams["figure.figsize"] = (5, 3)
    fig, ax = plt.subplots()
    ax.spines['top'].set_visible(False)
    ax.spines['right'].set_visible(False)
    ax.get_xaxis().tick_bottom()
    ax.get_yaxis().tick_left()
    plt.plot([0, 1, 2], [0, 1, 2], label="y=x")
    plt.plot([0, 1, 2], [1, 1.5, 2], label="y=x/2+1")
    plt.plot([0, 1, 2], [-1, 1, 3], label="y=2x-1")
    ax.label_lines()

I am unsure why the annotations are not being displayed in the image comparison test. What's confusing is that when I run the same code in the python REPL with plt.show() at the end, I see the annotations.

Image Comparison Test

REPL with plt.show()

Because they are off the page?

Because they are off the page?

@jklymak thanks but your comment is not helpful because there is space for them to partially render like plt.show() renders them.

Clipping? Note the tests are typically run with a different style than the default for historical reasons.

@jklymak we've made changes based on your feedback, I've marked your inline comments as resolved. We also added an example file and a new entry in doc/users/next_whats_new/.

We are working on unit tests and will push them as soon as they are done.

I wonder if the constrained layout engine could get repurposed to help solve the optimal text label position problem? It is already in matplotlib for other purposes. I am not familiar enough with it though to comment on whether or not it could be used.

There is a nice tool called adjustText which could be used to repell the texts from each other. With it, such graph could look like

import numpy as np; np.random.seed(42)
import matplotlib.pyplot as plt

def lines_legend(ax):
    from adjustText import adjust_text
    texts=[]
    for line in ax.lines:
        l = ax.annotate(line.get_label(), xy=(1, line.get_ydata()[-1]), xytext=(5,0),
                        xycoords=ax.get_yaxis_transform(), textcoords="offset points",
                        va="center", color=line.get_color())
        texts.append(l)
    
    adjust_text(texts, only_move={'points':'y', 'text':'y'}, ha='left',
                va="center", autoalign=False, ax=ax)
    
    
x = np.linspace(0,1,40)
y = np.cumsum(np.random.randn(40,10), axis=0)
labels = ["".join(np.random.choice(list("ABCDEMNOP"), size=8)) for i in range(10)]

fig, ax = plt.subplots()
fig.subplots_adjust(right=0.8)
for i, label in enumerate(labels):
    ax.plot(x, y[:,i], label=label)
        
lines_legend(ax)

plt.show()

The reason I'm mentioning it, is that I'm not sure if we really want such a highly specialized code for only one single purpose.
Or in other words, I would be in favour of either adding a general purpose "text-repeller" that could then be used for more than this special task, or not to add such thing at all and ask people to use the existing external tools for it.

I wonder if the constrained layout engine could get repurposed to help solve the optimal text label position problem? It is already in matplotlib for other purposes. I am not familiar enough with it though to comment on whether or not it could be used.

@WeatherGod thank you for your thought, we would need more guidance to make it actionable.

I am not too familiar with the internals of constrained layout, however, it seems to me that the problem constrained layout is trying to solve is a different layout problem than we are trying to solve.

1. Constrained layout adjusts the size of subplots to accommodate the size of axes and axes decorations. When laying out text near their data-points, nothing needs to be resized.

2. Constrained layout deals with two-dimensions. Laying out text near the end of lines is only concerned with one dimension.

We discussed this during the weekly call. This feature is cool, but as is, it is likely too brittle for main-library use. i.e. if we zoom, what happens? What happens if there are 300 lines? etc.

We strongly suggest anyone who wants to make this a feature to first write a third-party library, get it fully functional, and if the changes are not too invasive, then feel free to promote it for the main branch.

As for @WeatherGod's suggestion, you could indeed use something like kiwisolver to solve for the text positions, but it would probably need a different implementation (though you may be able to use _layout_boxes.py)

This may also be a good candidate to write up on the blog (https://github.com/matplotlib/matplotblog).

Thank you for the response, therefore would it be preferable to continue working on and improving our vertical text aligner, and implement it as an independent method which takes in a list of texts and aligns them without overlap using vertical spacing which is then used by label_lines. This would take the original position into account and try and place it as near as it can be to that position. Or would such a method still be too specific.

The biggest problem is that the text become de-coupled from the lines so if the user pans / zooms the labels no longer are in the right place. The aligning / de-conflicting needs to happen every time the view is changed. We have one example of text that does this (the code in clabel for labeling contours).

If you want to keep working on this the right place to start is to create a new artist class that knows about the Line2D objects it is labeling, has all of the text as children, and put the adjustment logic in it's draw method (and then call the draw method on all of the text objects).

If you use Annotation you can probably also get the gray connecting lines without too much extra work.

it is likely too brittle for main-library use. i.e. if we zoom, what happens? What happens if there are 300 lines? etc.

@jklymak with our current implementation annotations are deleted and re-added on zoom/pan. Since the line labeling routine is fast, the user experience has been smooth. We've tested it with up to 175 lines.

The biggest problem is that the text become de-coupled from the lines so if the user pans / zooms the labels no longer are in the right place.

@tacaswell

In the graph below, there are 175 lines. All 175 annotations don't fit on the screen, however, the annotations that show are in the correct order starting from the minimum.

When zooming in, the annotations get redrawn since the line ends are more sparsely populated.

Our algorithm runs in linear time with respect to the number of lines, it positions them precisely based on available space. @ImportanceOfBeingErnest demonstrated how adjustText could be used to solve the same problem. We would like to note that adjustText is an iterative estimator, which means it is slow and imprecise. Our solution is fast and precise (we don't try to estimate, we calculate exactly where things should go).

So, I finally got around to downloading this. Suggest the following example for testing based on @ImportanceOfBeingErnest above.

import numpy as np
import matplotlib.pyplot as plt

# Create plots with pre-defined labels.
fig, ax = plt.subplots(constrained_layout=False)
x = np.linspace(0,1,40)
Nlines = 400
y = np.cumsum(np.random.randn(40,Nlines), axis=0)
labels = ["".join(np.random.choice(list("ABCDEMNOP"), size=8)) for i in range(Nlines)]

for i, label in enumerate(labels):
    ax.plot(x, y[:,i], label=label)

ax.label_lines()

plt.show()

It actually all works pretty well. Sure if you have 400 lines the labels all overlap, but that seems fine. If you zoom the redraw, and if you pan around they refresh.

The only issue in my mind is that they are drawn in data space, so if you zoom they can go out of view. Not sure if it would't be better to just have them at x = 1 in axes co-ordinates, and just change their y value based on what lines are visible?

Otherwise this looks like a useful, relatively unobtrusive, addition.

@jklymak I think it's a good idea to move them out of the data space into the axes coordinates, it makes more sense for a label/legend anyways

I guess you should probably update the Bachelor's degree example to use this new function now, too.

@QuLogic will do!

Maybe worth comparing with https://github.com/nschloe/dufte?

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.