Can't see any obvious way of attaching a file in GitHub. Here's the output:

http://devio.us/~mspacek/freesans_example.png
http://devio.us/~mspacek/freesans_example.pdf

I've looked at the PDF in evince, which seems to indicate that FreeSans is indeed embedded in the file. I've also viewed it with PDF XChange Viewer, which shows the same distortion.

I'm running the latest from git by the way.

Can you post a screen capture of what you are seeing? This is unlikely to be a bug in mpl, but rather in the PDF renderer. Some PDF viewers share similar renderers, so the same distortion could show up in multiple readers.

Sure, here it is:

http://devio.us/~mspacek/freesans_screenshot.png

I can confirm that I get the same artifacts in Adobe Reader on my Android phone.

The system generating these PDFs is Ubuntu 11.04 with ttf-freefont 20090104-7

I can confirm this with version 20100919-5 of FreeSans and matplotlib git master.

As a workaround for now (as we get to the bottom of this bug), you can set the rcParam "pdf.fonttype" to 42. This will embed the entire TrueType font verbatim, so will result in larger PDF files, but the font glitches don't appear to be there.

Looks like ttconv has a bug in converting TrueType. The zero glyph in the pdf file includes this as the inner contour:

417 631 m
227 631 133 534 133 342 c
133 147 179 50 273 50 c
322 50 358 74 382 122 c
405 170 417 244 417 345 c
417 631 l

Compare this with the fontforge output from FreeSans.ttf:

275 631 m 132,-1,15
 133 631 133 631 133 342 c 0,16,17
 133 50 133 50 273 50 c 0,18,19
 347 50 347 50 382 122 c 128,-1,20
 417 194 417 194 417 345 c 0,21,14
 417 631 417 631 275 631 c 132,-1,15

The inner curveto endpoints match (133 342, 273 50, 382 122, 417 345) but the first and final points don't (417 631 vs 275 631; note that 417 631 looks like it's a control point of the final curveto in the ttf data). Also, the pdf data ends with a lineto but the ttf data ends with a curveto.

Does pull request #905 fix the problem?

Yes, #905 fixes it for me. Thanks Jouni!

Actually, I just noticed that in the .pdf, the FreeSans '1' doesn't align properly on both the x and y axes labels (see attachments above). It's too far to the right. This isn't really apparent in the .png, and doesn't happen with the default sans-serif font. Is this another truetype conversion bug? Should I file another bug?

Does changing pdf.fontType to 42 fix the alignment issue? If it does, then it could be another TTF to Type 3 conversion bug, but if it doesn't, it sounds more like a font metrics issue.

Changing pdf.fonttype to 42 doesn't seem to change the alignment of the FreeSans '1' on the axes. As before, the axes as displayed on screen and as saved to .png are fine, but in the .pdf the '1' is aligned somewhat too far to the right. I can tell I've correctly switched to using type 42 because the output .pdf files are much bigger than before.

Then I don't think it's a bug in the same component as the first one. Possibly the font metrics are read wrong.

OK, should I open up a separate issue for the alignment problem?

Yes, I'd suggest a separate issue for that. Please see if it is backend-dependent, or occurs in both agg and pdf (and possibly svg).

Merged into v1.1.x.