Confirmed in both v1.1.x and master. I suspect it has to do with closing the path incorrectly, but that is just wild speculation on my part.

@WeatherGod : I've moved this into the "1.2 known bugs" pile. Its one of those things which we would really love to get fixed for 1.2, but if we don't, we don't (at which point, it becomes a known bug). If somebody comes up with a solution to this before we take the rc1 1.2 cut though (or potentially even after?!?), then we are likely to integrate it as a matter of priority. How does that sound?

fine with me

What's the date for the 1.2 cut? I've got a bit of time right now to dig through it.

There is a calendar in the wiki: https://github.com/matplotlib/matplotlib/wiki
The date is set for the 17th. As for when we physically take the new 1.2.x branch I am not sure: I assume sometime before that.

If your happy to have a look into this, that would be fantastic! Just in case you have some difficulties, I believe the original author of the pdf backend was @jkseppan (correct me if I am mistaken), who should probably have some visibility of this issue anyway.

Thanks,

Thanks for the heads-up - I'll take a look today.

If @eeaston or somebody is looking at this now, my first suggestion would be to look at the the recent changes to src/_ttconv.cpp - I rewrote a bit there to fix a rendering problem with one font (I think zeros and eights looked odd), but perhaps the change breaks rendering of the % sign in this font. If you do find a way to fix this, please add a test case where a percent sign is rendered at large scale, so we can ensure that the regression doesn't occur again.

Apologies if I'm missing something, there's been no changes to src/_ttconv.cpp since 1.1.0?

Oops, sorry, I was thinking about the ttconv subdirectory, not src/_ttconv.

Hi there - I can confirm that the file that is causing this bug is indeed ttconv/pprdrv_tt2.cpp. As I'm not really a C++ dev however I don't rate my ability to actually fix this in any sane fashion, sorry!

I bisected the issue and the bug is introduced in dbc6ef2

I'm moving this to the 1.2 milestone, since it seems to me that #1222 is close to a solution (it still needs more testing).

This seems fine. The original code is not mine -- I merely converted it from a console application into a library and wrapped it for Python. I didn't notice at the time that it was doing all this extra work. Seems reasonable to cut it.

This doesn't seem to regress issue #905, which is great. I'm going to go ahead and merge.

Thanks!

Work-around: use latex rendering instead.

mpl.rcParams['pdf.fonttype']=42 fixed it for me

From: http://stackoverflow.com/questions/14295647/why-do-vector-based-image-files-contain-damaged-characters