Thx a lot you guys, as suggested by Jouni, it was indeed the line
ax.axvline(x=1, c='#00', lw='2', alpha=0.5)
which caused the problem. Jens' trick to change the backend also led me to
the same line as it complains about this misplaced string '2'.
You helped me a lot, I was clueless :),
Ghostscript's -dPDFDEBUG option pointed to an operation in the page
description that sets the line width to the string 2, which is
nonsensical. When I manually edited that to be the number 2, Adobe
Reader displayed the file. Does the source code by any chance include
something like this:
If you have Cairo installed and the matplotlib Cairo backend you could try
to test the
pdfs generated with this backend to see if they suffer from the same issue.
i.e. add
```
import matplotlib
matplotlib.use(cairo)
```
to the top of your script.
Depending on where the bug is this may or may not
buckeliger buckeli...@gmx.ch writes:
Hey, thx for the reply. The OS is hardly the problem as with the same input
files I can generate plots that work also in acroread.
Also, the file you linked to from the Stackoverflow question is just
72kB (and 84kB when uncompressed with pdftk) so it's
I have described and uploaded a sample file with the problem to
http://stackoverflow.com/questions/20314255/matplotlib-generated-pdf-cannot-be-viewed-in-acrobat-reader
http://stackoverflow.com/questions/20314255/matplotlib-generated-pdf-cannot-be-viewed-in-acrobat-reader
there they ment, I
You mentioned in the comments that it only occurs with a lot (~4 GB)of
data. Could it be that you're on a 32-bit system and you're generating a
file that's too big for your OS to handle?
On Tue, Dec 3, 2013 at 1:21 AM, buckeliger buckeli...@gmx.ch wrote:
I have described and uploaded a sample
Hey, thx for the reply. The OS is hardly the problem as with the same input
files I can generate plots that work also in acroread. And as you can
probably see, the example file I uploaded to UbuntuOne can be viewed in
evince etc. The problem occurs only if the data is being processed; if I
only
