---

Print Operations

An NSPrintOperation object controls the process that creates a print job. Print jobs are normally sent to a printer, but they can also be used to generate Portable Document Format (PDF) and Encapsulated PostScript (EPS) data for your application. An NSPrintOperation object does not generate the print code itself; it just controls the overall process, relying on an NSView object to generate the actual code.

NSPrintOperation works in conjunction with two other objects: an NSPrintInfo object, which specifies how the code should be generated, and an NSView object, which performs the actual code generation. You specify these two objects when you create an NSPrintOperation object. If no NSPrintInfo is specified, NSPrintOperation uses the application’s shared NSPrintInfo, which contains default values. (A shared NSPrintInfo object is automatically created for an application.)

The shared NSPrintInfo works well for applications that are not document-based. However, document-based applications should create an NSPrintInfo for each document that might be printed and use that object instead. This allows users to set printing attributes on a per-document basis.

Once created, a print operation can be configured in several ways. By default a print operation displays the Print panel to allow the user to modify the current print settings. You can prevent this with the setShowPanels: method. You can also tell the print operation to include a custom accessory view in the standard Print panel. The accessory view can present application-specific print settings to the user. (Print operations that create PDF or EPS data never display the Print panel.)

By default, the print operation performs the data generation on the current thread. This thread is normally the application’s main thread, or the thread that processes user events. You can tell the print operation to instead spawn a new thread and generate the print job on it, using the setCanSpawnSeparateThread: method. This allows your application to continue processing events, instead of blocking. (Print operations that create PDF or EPS data always run on the current thread.)

After configuring the print operation, you tell it to run by sending it the runOperation or runOperationModalForWindow:delegate:didRunSelector:contextInfo: message. The first runs the Print panel as an application modal dialog and blocks until the print operation completes. The second displays the Print panel as a sheet on a specified window and returns immediately, sending a message to the delegate when the print operation completes.

---