16
$\begingroup$

When I export even simple graphics, say, a DateListPlot to PDF under Windows, it refuses to print on any of the printers at work.
enter image description here

Acrobat (Reader X) throws three modal dialogs in succession: "The document could not be printed", "There were no pages selected to print" and (sometimes) "There was a drawing error".

Strangely, simple graphics (i.e. not a GraphicsGrid) will print correctly if you choose "Save Selection As..." or right-click and choose "Save Graphics As..." and save as a PDF. However PDFs produced using the Export command, or by saving some more complex Grids of graphics, have this printing issue. I cannot see anything different in the properties of the PDFs produced with Export that might cause them not to print, when those produced using the various versions of "Save As..." do print.

There is a work-around, which is to go into the Advanced tab of the print dialog and choose "Print as image".

Since the intention is that colleagues will be running notebooks that automatically update and export PDF-format graphics, I am reluctant to use this work-around. People will forget what to do and blame me. I have already had problems sending graphics to colleagues that they then can't print.

Other than manually exporting things all the time using "Save Selection As" and educating people on print settings, is there anything I can do to avoid printing errors?

System: Windows XP, Mathematica 8.0.4. We're going to Windows 7 very soon, so maybe that will help.

EDIT
I have now uploaded:

  1. The file that does not print (produced using Export)
  2. The file that does print

As you can see, they look identical but there are about 100 extra bytes in the Exported version.

EDIT 2

This bug seems to have been fixed in version 9.

$\endgroup$
17
  • $\begingroup$ I've experienced the same issue. I reported it many moons ago, but WRI couldn't reproduce on their system. I'm running Win 7, Mathematica 8.0.4. Maybe if enough people report it, WRI will give it another look. $\endgroup$
    – user936
    Commented Apr 5, 2012 at 3:25
  • $\begingroup$ Can't reproduce (ie works OK) in Mma 8.0.0 Win XP $\endgroup$ Commented Apr 5, 2012 at 3:45
  • $\begingroup$ Same issue with Mathematica 8.0.4 and Windows 7. $\endgroup$ Commented Apr 5, 2012 at 6:59
  • $\begingroup$ Experienced the same issue but couldn't figure out what exactly produces this behavior. Gave up basically. $\endgroup$ Commented Apr 5, 2012 at 10:47
  • $\begingroup$ I had no problems printing two Exported pdf's. One was just a ListPlot, the other a GraphicsGrid with two ListPlots and two bitmaps. Win 7/8.04, printer a very old (18 years and counting) Apple Laserwriter 360 postscript printer. $\endgroup$ Commented Apr 5, 2012 at 17:43

4 Answers 4

10
$\begingroup$

You might also have luck if you specify the ImageSize

Export[filename, plot, "PDF", ImageSize -> 8*72]

I have also been able to print files when using the Print As Image option (under Advanced from the Print menu of Adobe).

$\endgroup$
1
  • $\begingroup$ +1 this certainly works under Windows 7 using Mathematica 8.0.4 and Adobe Acrobat Pro X, at least for the test plot in the OP. $\endgroup$
    – Verbeia
    Commented Aug 23, 2012 at 9:27
15
$\begingroup$

Short answer: I hope Export["foo.pdf", plot,Background->None] fixes it.


Let's get there step by step.

  1. First, Acrobat X Pro on my Mac reports that both your PDF files are fine. They print fine, and pass all tests with flying colors.
  2. I uncompressed the PDF (thanks pdftk) and a diff on them reveals that one weird object that only appears in your “export” PDF (i.e. the semi-broken one):

    -2147483648 -2147483648 m
    -2147483648 2147483647 l
    2147483647 2147483647 l
    2147483647 -2147483648 l
    W* n
    

    The numbers are INT_MIN and INT_MAX, the smallest negative 32-bit integer and the largest positive 32-bit integer. So, an infinitely large rectangle is being drawn.

  3. Then, I imported the PDFs and put them over a colored background:

    enter image description here

    The conclusion is: “export” gives the PDF a white background (why not), and it does this by drawing a white rectangle of infinite size below all other objects (weird!).

  4. Searching the documentation for “PDF export background” brings up the doc for EPS export, which has an option:

    Background           Automatic           background color shown in transparent image regions

    Now, I tried to use it as Export["foo.pdf", plot, Background->None] on my Mac, and it works only half-way: the white background is gone, but there still is an infinite invisible rectangle behind. So, I hope this is enough to fix your issue.


As a side note, I'll just state that as far as I understand the PDF Reference, having an object (even of very large size) outside the page box is not invalid. So, one could probably argue that the PDF is valid, and either the viewer application or your driver (on some systems, PDF printing directly sends the PDF to the printer driver) is at fault for not dealing with it properly.

$\endgroup$
7
$\begingroup$

I thought this might be useful information for users. WRI tech support say this is a bug. However if you open the exported PDF in the open source PDF reader Evince then you can print.

$\endgroup$
1
  • 1
    $\begingroup$ Note that Background->None was not a fix for my problem. $\endgroup$ Commented Aug 24, 2012 at 23:16
4
$\begingroup$

This problem of not printing Exported PDFs originated when upgrading from version 7 to version 8. In version 7 it worked fine. In February 2011, I complained to Wolfram Research, as a Premier Service Member, but they could not fix this at the time.

By trial and error I have stumbled upon a workaround. Export the graphics as a Postscript file:

Export["Math/output/file.eps", graphics, "EPS"]

and then use the Unix convert to make PDF

convert file.eps file.pdf

I can open this in Mac Preview and now it prints fine on my old Epson CX21 laserprinter. I use Mathematica 8.0.1 on Mac OSX 10.6.8.

I hope this helps.

$\endgroup$
1
  • 6
    $\begingroup$ Note however that convert produces a pixel format. If you want to keep a vector format, use epstopdf instead. $\endgroup$
    – celtschk
    Commented May 4, 2012 at 13:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.