Repository navigation
some FreeSans characters distorted in PDF backend #903
Description
Having just tried saving to .pdf with MPL for the first time in years (potentially in place of .png, for embedding in .tex files), it looks great, except for an obvious glitch. I'm using FreeSans as my default font in rcParams, 13 pt size, and when saving to .pdf, the '0' character comes out distorted. Same goes for 'B' and '8', but none others that I can tell. This doesn't happen when saving to .png. Here's the example code
plot(np.arange(10))
text(0, 5, 'abcdefghijklmnopqrstuvwxyz\nABCDEFGHIJKLMNOPQRSTUVWXYZ\n012345687890\n~!@#$%^&*()_+-=')
gcf().savefig('freesans_example.png')
gcf().savefig('freesans_example.pdf')You'll have to set FreeSans as your default in rcParams to replicate this, or pass it the appropriate way when plotting or adding the text. I'll see if I can attach the output.
I suppose since this doesn't happen in the .png, this must be a PDF backend bug, and not some quirk in FreeSans?
Martin
Metadata
Metadata
Assignees
Labels
No labels
Activity
mspacek commentedon May 25, 2012
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.
mspacek commentedon May 25, 2012
I'm running the latest from git by the way.
WeatherGod commentedon May 26, 2012
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.
mspacek commentedon May 26, 2012
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
mdboom commentedon May 26, 2012
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.
jkseppan commentedon May 26, 2012
Looks like ttconv has a bug in converting TrueType. The zero glyph in the pdf file includes this as the inner contour:
Compare this with the fontforge output from FreeSans.ttf:
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.
jkseppan commentedon May 27, 2012
Does pull request #905 fix the problem?
mspacek commentedon May 27, 2012
Yes, #905 fixes it for me. Thanks Jouni!
mspacek commentedon May 27, 2012
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?
jkseppan commentedon May 28, 2012
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.
mspacek commentedon May 28, 2012
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.
jkseppan commentedon May 28, 2012
Then I don't think it's a bug in the same component as the first one. Possibly the font metrics are read wrong.
mspacek commentedon May 29, 2012
OK, should I open up a separate issue for the alignment problem?
jkseppan commentedon May 29, 2012
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).
Add a test case for ttconv
jkseppan commentedon May 31, 2012
Merged into v1.1.x.