I've been working with an FM 11 book and chapter files for about 2 months. Within the last two days, I suddenly cannot print the book any more. Selecting File > Print Book... and the only thing that happens is the files in the book are selected/highlighted and I see a Pages: message at the bottom of the book window with the page ranges from each file listed (e.g., Pages: 1 - 2, i - x, 1 - 16,....)
As far as I know, I haven't changed any settings. I've been printing the book this way for weeks. Now... nothing. I have been able to use File > Save as PDF...
Thoughts or help, please? I've Googled and searched this forum, but have not found an answer. I'm guessing it's something simple I have overlooked.
I have migrated to a new machine this last week, but I was able to print following that migration -- at least a few times.
Windows 7 64-bit
Acrobat and Distiller XI
What is the printer instance that you're printing to? What is the port configuration for that instance?
If you're creating PDFs, then the SaveAsPDF route is quite reliable now - no need to print to a .ps file and distill.
Jeff's suggestion to update did the trick. But to answer your question, I was not able to get to a printer selection dialog. The program would simply highlight those files and I was stuck there, but the program would respond.
Looking back at it now, I wonder if the print dialog was hanging off the edge of the viewable page. I am running a multiple monitor setup and something could have accidentally been dragged off. I think FM remembers that dialog location and therefore it was appearing out of view -- making it look like I was stuck.
Whether it was a bug, or whether updgrading to build .384 "reset" the dialog position, it is working again.
I am curious about your comment on SaveAsPDF functionality. I guess I'm "old school" with the print to file .ps and then distill. I have researched this recently, but there are so many opinions. I would love to hear your thoughts or see what references to articles/procedures you have.
The SaveAsPDF routines have been quite stable for the last few releases of FM (i.e. the 10.0.2 patch). The only reason to use the manual method would be for a very specific print/press requirements where you need to handle the postscript for some reason (such as specific colour tweaking, graphic insertion, variable data or device-specific job information) before handing it off to Distiller.
If you're only creating PDFs for online use or office-quality print jobs, then the "old way" is more manual work and file maintenance chores on top of your existing workload.
I generally accept the defaults, or pretty close to it, for High Quality Print (for internal documents that must look great) or Press Quality (when sending manuals or other technical document to a professional printer. They have not had any specific requirements for me other than what I've been sending them as print-ready PDFs.
I just want to ask about your comment about graphic insertion. Do you mean graphics inserted outside of the authoring workflow? My documents are extreemly graphics intensive with a mix of custom illustrations (Illustrator .eps or .ai) as well as enhanced digital images (.psd, .jpg, or .png). "Back in the day" I was taught to distill to preserve quality and avoid issues with post-script.
Is that not necessary anymore if I'm really only using the default High Quality or Press Quality settings? The only other "fancy" stuff I watch out for is font embedding and creating hyperlinks/bookmarks, etc. And I see I can do that with the SaveAsPDF functionality.
Thanks for your insight on this. If you have any references you trust on this, I'm happy to do my own research. But my digging around to date has yielded a lot of different opinions about the quality/safety of SaveAsPDF vs. Distiller.
SaveAsPDF sure would make my life easier. Seems like I'm doing this at least a couple times a day when I combine internal review/print needs and requirements for sending documents to external printers.
Regarding the graphics insertion, this is more for inserting hi-res images after the fact (image by-pass processing for speed and small ps files). In colour catalog production, full-page colour images can be very large, so instead of generating gigabytes of postscript from FM, these can be called into the Distiller processing as external references - passing the onus on to Distiller to do the heavy lifting.
What you mention about distilling to preserve quality and avoid issues, is exactly what happens regardless of the route you choose. The SaveAsPDF just automates things behind the scenes - it still creates a postscript file (except it's labelled as a .tps), calls Distiller with the specified joboption, deletes the .tps afterwards and optionally displays the final PDF. There ar some optimizations that are performed on the .tps prior to handing over to Distiller as well, that ar not available when you manually create the .ps and distill. You also cannot call the FM CMYK output routines from the manual route. In the intial installations, there were issues arising when the default printer wasn't the AdobePDF printer instance and FM tried to set the correct printer in the background (but often messed up when multiple postscript devices were available). Ther also were issues when the Acrobat team changed the printer instance name and default locations for some files (joboptions) in the mid-cycle of a FM release, so users with newer versions of Acrobat ran into "phunnies" happening to their output.
If you were having quality issues before, it was most likely incorrect job-option file settings, not having the AdobePDF set as the default printer instance (and/or user error).
The one thing to be aware of is the first time you run the SaveAsPDF, it may take quite a bit longer to create the PDF file. This is due to the background initalization and calling of Distiller and some of the postscript processes. However, once it's been done, subsequent PDFs created in the same FM session fly out the door (so to say). With really big, graphically complex jobs, it may be advantagous to create a small PDF of something simple first. There also is minimal feedback when the SaveAsPDF process is running (which is just a poor UX-design in my opinion).