closes #12265

@anntzer @ImportanceOfBeingErnest I'm not sure how to add tests for this. Would need a bit of guidance.

A test would sit either in matplotlib/lib/mpl_toolkits/tests/test_axisartist_axislines.py, matplotlib/lib/mpl_toolkits/tests/test_axisartist_grid_helper_curvelinear.py.

As test you may choose the most minimal, yet general code that would produce this behaviour. Two options are:

1. Create a "smoketest", i.e. just put the code there. If it throws an error, the test would fail.
2. Create an image comparisson test. For this you would need to create a target image.

Both are explained in https://matplotlib.org/devel/testing.html

Thanks @kmuehlbauer !

Since image comparisson tests are a little expensive, I think one would benefit from creating one single figure with 3 subplots (one for pcolor, one for pcolormesh, one for contour and contourf) instead of 4 individual figures.

In general, you may by now have noticed that axisartist is pretty undertested. Since it seems you are using the axisartist toolkit a lot in your radar image library, there may be other cases you may not want to fail in future versions of matplotlib. Hence, please feel welcome to add additional tests (possibly in future PRs).

@ImportanceOfBeingErnest You are completely right, I'll change it as suggested as soon as possible.

Yes, we use the toolkits quite extensively. Time to give something back, I think.

So what's happening now is that the tests fail (Seen by the red "Some checks were not successful") because of some deviation between the produced image and the target image. This is most often the case when the freetype library in use differs from the one the tests are run with. The two alternative solutions to this are:

1. Make sure to use the same freetype when compiling matplotlib. This is shown here
2. Use remove_text=True in the image comparisson decorator. (Which is fine as long as the test isn't really testing anything which requires any texts to be rendered.)

As we are already talking about re-generating the images there is also a style option (which should be set to 'default').

Can you please make sure to squash the image commits (so we don't carry around the un-used images in git).

[edited to remove redundant requests]

@ImportanceOfBeingErnest @tacaswell I'll force push to my branch, to clean the history.

The problem I'm facing, is not the text, but the contour-lines (created from contour) which differ sometimes. Any ideas?

You see the little dot in the lower right part? That is one corner of the contour line. Only one pixel is different. I know, we have the tol keyword but I'm unsure why this happens. Normally the contourlines should exactly be the same.

The RMS was below 0.039 in all cases. So I set tol with a safety margin to 0.05 .

Safety margin wasn't good enough. Will fix this the next day...

rebased on top of current master due to conflicts

@anntzer, @ImportanceOfBeingErnest This is good to go from my end. Due to the erratic behaviour of contour I had to set the image comparison tol to 0.075 (it broke last time at 0.052). Let me know, if there is anything to do within this PR.