I just realized that when I introduced my testcase in __init__.py, I used an older version of this file by mistake. Basically, my commit a28c665 is screwed... I guess that amending is not a good practice. Maybe I should start a fresh branch !

@pierre-haessig : Thanks for doing this. It is a very useful fix which, as is, provides a good improvement in performance for large, non visible lines. As you can see, I've posted a couple of comments, none of which are major, but I have raised a question on the mpl-devel mailinglist about a possible alternative approach to resolving (and testing) this issue. I think we should hang fire on merging this for a couple of days/week(s) until that discussion has happened, but if the decision is against my proposal, what you have implemented here is the correct way to go.

Thanks again for doing this,

Phil

@pelson : Thank you very much for your feedback.

I've updated the README to only redirects people to devel doc. To answer @mdboom question about the new docs, I found the testing section immensely useful, because first I was very frustrated of my test not being found (I'm not familiar with nose, but I thought there was some automatic test discovery feature... ).

Then I found the solution by looking into the docs and that's why I made this small copy pasting which I agree is a pretty bad practice...
I think that putting a link to the docs in this README file is useful though.

About Travis build failing, I don't know what to do. Something is going wrong in the matplotlib.tests.test_mathtext where image comparison are involved. From what I see, the baseline image test_mathtext/mathfont_cm_00.png is 525x75 pixels while the test run creates a 800x600 images that it tries to compare with baseline. Thus the ValueError about shape mismatch.

This being said, I have no clue why the test wants to create a 800x600 image, especially since figure size is set by figsize=(5.25, 0.75)... Any ideas ? :-)

Any ideas ? :-)

Yes. Whenever you use pyplot for testing, you must either declare it as an Image test, or tell it to clearup after itself, the appropriate docs can be found here (don't worry, these have only just been added, and previously the cleanup decorator was undocumented).

Hope that does it!

@pelson, thanks for the explanation about the cleanup decorator. Hopefully, commit aacddf1 will resolve the test failures.

I suggest to use the .. warning:: Sphinx directive in the documentation to emphasize the need for this decorator with a nice red box. What do you think ?

Thanks to @pelson's help, there is no more Travis build failure :-)

Now I see two remaining issues:

• the commit history of this pull request not pretty clean. Maybe some rebase is needed, but I'm not a git guru so I don't know really what to do, especially since these commits are already pushed online.
• my master branch is lagging behind the main mpl master. I don't know if that's a problem for the PR... again I'm not a git guru !

@pierre-haessig You don't need to incorporate the latest changes from master. At present, your pull request will merge cleanly in its current state. However if you wish to tidy up your commit history, you will need to interactively rebase the last 5 commits with git rebase -i HEAD~5. If you don't feel comfortable doing this, I can rebase them for you and tidy up the commits.

@dmcdougall I dived back in Pro Git book and ran git rebase -i HEAD~5. Apparently it ran successfully an returned:

Successfully rebased and updated refs/heads/master.

However, I see no effect on my commit history (I still see the 5 separate commits). I suspect it may relate to the fact I'm not working on a topic branch but on my master branch (which prooves itself pretty annoying...).
Now that my git history is maybe screwed I may wait before trying to git pull.

If you have any further git tips, I'll be glad to play a bit more ;-)

@pierre-haessig Sounds like when you ran it, an editor popped up and you didn't change anything. If you try it again, read the stuff at the bottom of the text file that pops up. You can change commit messages and squash commits and such like.

Let me know how you get on.

@dmcdougall, you're right, I didn't change anything when the text editor popped up because I thought the default proposition was fine... I was wrong.
I finally found proper explanations about git rebase -i in http://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits and now I think my rebase went through ! (cf. c94c730)

I pushed with the --force option as I expected to be forced too... and apparently github swallowed that push smoothly :-)

@pierre-haessig I dig the verbose commit message. Thanks. I'll let Travis finish up the test just for sanity's sake.

@pelson It appears, judging by the feedback on the mailing list, that the use of Meta on Artist is not encouraged in its most general setting. Are you happy with the solution presented here?

Are you happy with the solution presented here?

Yep. Good work @pierre-haessig 👍

Thank you all for your kind help and thanks for merging so fast. With this tiny PR, I've learned a lot about git, mpl testing and mpl code.

With this tiny PR, I've learned a lot about git, mpl testing and mpl code.

Great to hear! We're always looking for contributors such as yourself and I hope this experience has encouraged you to get involved and submit further mpl pull requests 😄.

Cheers,