Hello David,

When you write, "[w]e tried saving to a PDF, but we're unsuccessful using that approach as well", do you mean that the creation of the PDF failed or that printing of the resulting PDF fails?

Could you try the following procedure? For each Graphics3D output cell: a) select the cell bracket b) invoke the menu command Cell -> Convert To -> Bitmap Attempt to print the notebook.

When printing a page (or generating a PDF through the Print dialog), Graphics3D output is rasterized at the printer resolution (usually 600 ppi). This may exhaust the memory on the lab printer. The procedure above rasterizes the Graphics3D at 72 ppi. It will produce much smaller image sizes at the expense of print quality.

Please let me know how this turns out.

Thanks, Chris

If you plan to use this as a workaround, you may find this snippet of code useful:

Module[{nb = EvaluationNotebook[]}, 
 NotebookFind[nb, "Output", All, CellStyle, AutoScroll -> False];
 FrontEndTokenExecute[nb, "SelectionConvert", "Bitmap"]]

Evaluated in the notebook you want to print, it will convert all Output cells to bitmaps. You could also change EvaluationNotebook[] to SelectedNotebook[] and use this procedure as the action of a button in a palette:

CreatePalette[
 Button["Convert Output to Bitmaps", 
  Module[{nb = SelectedNotebook[]}, 
   NotebookFind[nb, "Output", All, CellStyle, AutoScroll -> False];
   FrontEndTokenExecute[nb, "SelectionConvert", "Bitmap"]]]]

Unfortunately, this converts all Output cells to bitmaps even when they are not graphical.

What precisely happens when you try to create a PDF? I assume you are using the Print dialog and selecting PDF -> Save as PDF.... Please let me know if you are doing something different such as using the Save as... dialog.

Thanks.

I do not have an explanation for why the older iMac is unable to print while the newer one can. The Mathematica FrontEnd process is 32-bit so it cannot directly benefit from the increased RAM. The Kernel process does benefit, but usually it's only involved in printing when the notebook contains Dynamics. In my own testing, the FrontEnd process did not use more than 320 MB, and the Kernel used less than 52 MB while printing your attached notebook. I believe the issue is with the available memory at the printer, and there may also be some timeout related to how long it takes to render the notebook for printing. Reducing the raster size of the output cells solves these problems.

I was able to Save As PDF on my MacBook Pro (circa 2013), but I had to wait a couple of minutes and did observe the spinning beachball.