I'd like to be as specific as possible: Which artists aside from texts need this?
If we cannot be more specific here, we should write "Always call ..."

I guess I largely know of texts. I guess there may be some artists that are proportional to the figure or axes size?

I feel that vague statements are rather confusing to the user. We should do either

• dig into this deeper and explicitly write out for which artists this is necessary. - This is some work.
• State that users should always call draw_without_rendering before using get_window_extent(). - I'm a bit uneasy with that because we're forcing additional code and overhead on the user also in cases that would work without it.

I suggest to move this to a separate PR to not block the ticks stuff.

Note also that #22122 now mentions draw_without_rendering() in the Text.get_window_extent() exception, so that discussing draw_without_rendering() here for that case is less important now. If the error happens, the user has the solution at hand.

I don't think people are coming to a "How to" for the exact reason their artist extent is wrong - they just want to fix it. I don't think we need to enumerate all the troublesome artists, or interactions with layout managers etc here - we just want to tell them to call a fake draw and see if that helps.

Ok.

I find the examples a bit extensive. Would the following be sufficient?

import matplotlib.pyplot as plt
import numpy as np

fig, ax = plt.subplots(1, 2, constrained_layout=True, figsize=(6, 2))

ax[0].set_title('Ticks seem out of order / misplaced')
x = ['5', '20', '1', '9']  # strings
y = [5, 20, 1, 9]
ax[0].plot(x, y, 'd')
ax[0].tick_params(axis='x', labelcolor='red', labelsize=14)

ax[1].set_title('Many ticks')
x = [str(xx) for xx in np.arange(100)]  # strings
y = np.arange(100)
ax[1].plot(x, y)
ax[1].tick_params(axis='x', labelcolor='red', labelsize=14)

I see that you have updated the examples, and they are more clear now.

Still, do we need more than a screen full of figures and code to illustrate the relatively simple fact "passing string data plots all values as ticks in the given order"?

Motivation for the proposed plot above:

• I've limited this to the error cases. Plotting them is helpful to see how strings typically show up as "wrong" itics
• I've left out the respective "correct" plots with numbers for brevity. It should be quite clear from highlighted ticks that these are undesired. How the correct plot looks does not add much information IMHO.
• I've chosen two plots which show the characteristic error signatures "wrong order" and "too many ticks"
  "Dates out of order" is essentially the same as "numbers out of order".

I favor this to reduce clutter and keep the information density high. But I won't fight over it. If you feel strongly on having the correct plot as well, I suggest to at least remove the dates and use the same layout in both plots to make them equal in size.

My apologies, I wrote a reply, but must have closed it before hitting save....

a) datetime-as-string is a very common failure mode, so I think it should be in the FAQ
b) for beginners "turn your strings into floats" is going to require a google search; half the time, even I have to look up how to do datetimes. I felt it was important to offer a basic solution, and also to show the "expected" output so the "unexpected" is crystal clear.

This section is for folks who are trying to do their first plot, reading their Excel data in as a csv. While I agree we should be as concise as possible, I think here the extra guidance is worth the virtual real estate to get them on the right path.

This section is for folks who are trying to do their first plot, reading their Excel data in as a csv.

IMHO this can happen with all levels of experience.

Anyway, this is a judgement call on the audience and the amount of detail we think is necessary. I appreciate your position, but cannot sign-off on it. If others approve and merge I'm fine with that.

I mean its a How-To - I would argue we should provide concrete solutions.

It‘s not really a how-to, it‘s only in how-to because we don‘t have the proper category yet. #21943 (comment)

Let me rephrase: whatever we call it, I think it should have a solution in it, not just the problem.

To me the solution is „don‘t pass in strings“. How to get from strings to numerical values depends on the data source and values, and is beyond Matplotlibs business. Note for example that the canonical solution for pandas.read_csv would be to pass converters for those values and not create a numpy array from the data after loading.

I‘m fine that some people may have to do an additional google search. As said, it‘s a judgement call.

OK, well, lets move the full example into an example.

I see that you have updated the examples, and they are more clear now.

Still, do we need more than a screen full of figures and code to illustrate the relatively simple fact "passing string data plots all values as ticks in the given order"?

Motivation for the proposed plot above:

• I've limited this to the error cases. Plotting them is helpful to see how strings typically show up as "wrong" itics
• I've left out the respective "correct" plots with numbers for brevity. It should be quite clear from highlighted ticks that these are undesired. How the correct plot looks does not add much information IMHO.
• I've chosen two plots which show the characteristic error signatures "wrong order" and "too many ticks"
  "Dates out of order" is essentially the same as "numbers out of order".

I favor this to reduce clutter and keep the information density high. But I won't fight over it. If you feel strongly on having the correct plot as well, I suggest to at least remove the dates and use the same layout in both plots to make them equal in size.

Needs updating for the changed example code below.

I feel that vague statements are rather confusing to the user. We should do either

• dig into this deeper and explicitly write out for which artists this is necessary. - This is some work.
• State that users should always call draw_without_rendering before using get_window_extent(). - I'm a bit uneasy with that because we're forcing additional code and overhead on the user also in cases that would work without it.

I suggest to move this to a separate PR to not block the ticks stuff.

Note also that #22122 now mentions draw_without_rendering() in the Text.get_window_extent() exception, so that discussing draw_without_rendering() here for that case is less important now. If the error happens, the user has the solution at hand.