Repository navigation
Error with greek letters in pdf export when using usetex=True and mathptmx #16087
Description
When I export a pdf with savefig I have errors in the greek letters, but only in the pdf the png export is fine. I use the option "usetex=True" and the package "mathptmx".
import matplotlib.pyplot as plt
from matplotlib import rc
import matplotlib
rc('text', usetex=True)
rc('text.latex',preamble= [
r"\usepackage{mathptmx}",
])
x = range(10)
plt.figure()
plt.plot(x, label = r'$\varphi$')
plt.legend()
plt.xlabel('abcdefgh')
name = matplotlib.__version__
plt.savefig('mpl_'+name+'.pdf')
plt.savefig('mpl_'+name+'.png')
plt.show()With the provided code you will get a png and a pdf file. In the pdf file the \varphi symbol in the legend is only a long line. With version 2.2.4 and 1.5.3 this happens. With Version 1.4.3 the pdf and the png is fine.
Matplotlib version
- Operating system: MacOS 10.12.6
- Matplotlib version: 2.2.4, 1.5.3 and 1.4.3 tested
- Matplotlib backend: MacOSX
- Python version: 2.7.17
All instalations done via macports.
Attached the output files:
Version 1.4.3
mpl_1.4.3.pdf
Version 1.5.3
mpl_1.5.3.pdf
Version 2.2.4
mpl_2.2.4.pdf
Screenshot of error in pdf
Activity
tacaswell commented on Jan 4, 2020
Can you try with different pdf viewers? If I download your pdfs and look at them in chrome or okular (or docview in emacs) the look correct.
If I squint, I could believe that the line is a very distorted version of phi.
I took a quick look at the API and release notes for 1.5.0 and nothing jumped out at me as being related.
markushartmann commented on Jan 4, 2020
With Adobe reader another error is displayed. The reader message is that the font "StandardSymL_Slant_167" could not be extracted (attached Screenshot).
For me it sounds simmilar to issue #11259
markushartmann commented on Jan 10, 2020
Any ideas how to debug this problem a little bit more?
#9139 seams to be very similar
anntzer commented on Mar 24, 2020
attn @arm2arm from #16894 as well.
If anyone has access to Acrobat Pro, can you try running preflight (https://helpx.adobe.com/acrobat/using/analyzing-documents-preflight-tool-acrobat.html) on one of the "bad" pdf docs and see what comes out?
arm2arm commented on Mar 25, 2020
pdf and report
test_arman_report.pdf
test (1).pdf
anntzer commented on Mar 25, 2020
So Adobe is just complaining about some bad glyph widths. This can be fixed manually, as I've done in the attached file here: test.1.pdf
But locally Acrobat DC still fails to open the new file. Is that also the case for you?
I'm also confused that apparently preflight does extract the glyphs just fine, but for some reason the pdf viewer refuses to display them.
arm2arm commented on Mar 27, 2020
So same failure, but the MS Edge can preview that as before.
anntzer commented on Mar 27, 2020
Well, that's annoying because we can't even know why Acrobat complains about that file (as you mention, edge is happy with it; on linux, poppler and mupdf-based readers are fine too, as is chromium). Any chance you could contact Adobe to ask them what's wrong with the file, or whether it's something on their side?
jkseppan commented on Jul 27, 2020
This was a weird one! I compared to the output of pdftex, and the only major differences in the embedded font I saw were:
vs. pdftex's
Because Type 1 is a subset of PostScript and PostScript interpreters typically only support single-precision floating point, I suspect that their parsers return some bogus value for 0.00016700000000000002. Reducing the precision on these numbers seems to help at least with Preview.app.
I'm preparing a patch, but in the meanwhile people with other pdf readers could see if the attached file works better.
issue16087.pdf
Reduce numerical precision in Type 1 fonts