I tried to take a look but, pstopdf in my linux box works okay (it
converted test_tex_r8216.eps fine also) and I'm afraid that I may not
be able to track this down.
Just in case, can you check if using a different distiller makes any
difference? I believe you're using a ghostscript (or none
On Fri, Apr 2, 2010 at 11:20 AM, Michael Droettboom md...@stsci.edu wrote:
It seems the relevant change is in r8102: fix some issues in the bbox
after the postscript distiller is run. This change removed a commented
out call to ps2eps. I'm a bit out of my depth here as to why that
change was
It seems that removing 'restore' on line 1073 of the test_tex_r8216.eps file
fixes the problem, although I don't understand postscript well enough to
understand why that is.
Thomas
On Apr 2, 2010, at 9:30 AM, Michael Droettboom wrote:
Can you provide us with the EPS file? What version of
I just had a quick look, but while extra restore could be a problem,
the erroneous one may not be the one at line 1073, but the one at line
1066.
I believe that the restore at 1073 is written by pstoeps function
in backend_ps.py, and this function did write a matching save at
line 11.
Regards,
At least on my Linux box with gs 7.07, I have to use epstopdf (not
pstopdf) to convert an eps file to a pdf. ps2pdf does work for both .ps
and .eps files however.
It looks like the 0.99.1.1 file is not in fact an .eps file, but a .ps
file, (it certainly hasn't had the ps2eps function run on
I just tried running epstopdf, and this does work correctly, so maybe now the
only issue is that Preview.app on mac always uses pstopdf, even for eps files?
(which then is not a matplotlib issue) I also checked that giving the file the
extension '.ps' produces a ps file, and that does open
Hello,
I upgraded to the latest svn version of matplotlib today, and found that eps
files produced with the system latex now seem to be invalid. For example, if I
run the following script
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as mpl
mpl.rc('text', usetex=False)
fig
