The Mac OS X printing architecture consists of a number of modules that work together to
Present all printing user-interface elements
Accept raw drawing commands from applications and spool the data to be printed
Render print jobs to the destination printer
Each component of the printing architecture is designed to do a particular printing task. For example, a printer browser looks for available printers of a specific type (LPR, AppleTalk, USB, and so forth) while Print Center provides the user interface through which the user can choose printers and monitor printer activity. This specialization makes it possible for parts of the printing system to achieve new functionality or be extended by Apple in the future. Some components can be extended by developers. (See “Developing Software” for more information.)
Developers can leverage existing components and concentrate their coding efforts on specific needs. For example, printer vendors need only to write code that specifies the data format needed by the printer, processes the converted data, and handles printer status and error conditions. Developers use an Apple-provided converter to provide data in their specified format and an Apple-provided I/O module to communicate the data to the printer. Leveraging the existing converter and I/O modules makes writing a printer module easier than writing a printer driver for Mac OS 8 and 9.
The rest of this chapter describes the Mac OS X printing architecture in detail and provides an overview on how information about a print job is tracked by the printing system. When you have read this chapter, you should see “Developing Software” for resources to get you started developing software for the printing system.
The Mac OS X printing architecture is shown in Figure 2-1. Conceptually, the components of the printing architecture can be divided into three categories: application, server, and printer.
Application components are the Application Services and Carbon frameworks. These define the base printing application programming interface (API). Cocoa sits on top of the base API; Cocoa methods call through to the printing API defined in the Application Services and Carbon frameworks.
Server components include the print server, the Print Center application, and printer browser modules. The print server holds print jobs until they can be printed. Print Center provides the user interface to the print server, and printer browser modules discover printers that can be added to Print Center.
Printer components consist of four modules that work together to prepare and communicate a print job to a specific printer—print job manager, converter, printer module, and I/O module.
Each component is discussed in more detail in the sections that follow.
In Mac OS X, the printing application programming interface has two parts—the Application Services framework and the Carbon framework. Carbon applications need to link to one or both of these frameworks to call the functions available in the printing API. Cocoa applications need to link to the Application Kit, which in turn links to the appropriate printing frameworks.
Applications draw each page of the document to be printed and provide the printing system with all page format and print settings for the print job. The printing system can receive drawing commands from an application in several ways. Cocoa applications use the Cocoa drawing routines. Carbon applications commonly use QuickDraw but can use Quartz 2D if they want to take full advantage of Mac OS X’s graphics capabilities.)
The printing system creates a spool file from the drawing done by the application. Portable document format (PDF) is the standard spool file format, but PICT with PostScript is supported for backward compatibility with those applications that must generate their own PostScript when printing to PostScript printers.
The server components consists of the print server, the Print Center application, and printer browser modules. The print server accepts print jobs from applications and holds each print job in a queue until the specified printer is available to print the job. The Print Center application is the user interface to the print server, and can be used to view and manage print jobs in the printer queue. Print Center also reports status, including errors, should any occur. Printer browser modules look for available network and local printers, then provide the list of available printers to Print Center for display to the user. See “Print Center” for detailed information on adding printers and managing print jobs.
Four modules work together to prepare and communicate a print job to a specific printer—print job manager, converter, printer module, and I/O module. The print job manager accepts print jobs from the print server and then mediates among the three other modules (converter, printer module, and I/O module) to get the job printed on a specific printer.
A converter is an optional module that converts a document description from one document format to another. The print job manager determines how to convert the data properly for the chosen printer and configures the converter appropriately. A converter also retrieves the correct color profiles for standard ColorSync color matching during the rendering or conversion of the print data. In general, a converter takes PDF data and converts it to another output format such as raster or PostScript.
Printer modules (the analogues to printer drivers in Mac OS 8 and 9) are typically created by printer vendors to support a particular printer or printer family. The printer module determines, at runtime, the type of data it needs to produce the correct output on the printer. It communicates its needs to the print job manager, which uses the necessary converters to get the print data in the correct format. The printer module finishes processing the converted print data before it goes to the printer and also handles printer status and error conditions.
An I/O module provides a way to communicate with printers using a standard interface for a transport type. The module establishes a connection with a device, sends print data and commands to the device, receives status information from the device, and closes the connection at the appropriate time. I/O modules have limited or no knowledge of data formats, control commands, or printer capabilities. The modules simply pass through data.
Apple supplies I/O modules for LPR, USB, and AppleTalk. For those I/O types, printer vendors should use Apple’s I/O modules to communicate with their devices rather than develop new ones. (See “Supporting Printers ” for more information on developing I/O modules.)
There are two types of containers used to communicate information related to a print job—printing objects and printing tickets. Printing objects are used by applications; printing tickets are used by the printing system and printing plug-ins (such as a printer module or printing dialog extension).
Printing objects are opaque data structures used by applications to hold information about a print job. The two primary printing objects are the page format and print settings objects. The page format object stores information about how pages of a document should be formatted, such as paper size and orientation. The print settings object stores information from the Print dialog, such as page range and number of copies as well as other information about how the job should be printed on the destination printer. The printing system instantiates each object with default settings provided by the default formatting printer (for the page format object) and the default printer (for the print settings object).
The application uses accessor functions from the printing application programming interface to obtain and set values in these objects. The Page Setup and Print dialogs display information from these objects to the user. When the user modifies a setting in a printing dialog, the printing system writes the modified value to the appropriate object.
Tickets are opaque data structures used by the printing system, printer modules, and printing dialog extensions to communicate information about a print job. Applications do not, and should not, use tickets directly. The printing objects used by applications provide a view of the ticket data that shows only those items essential to the application.
You can skip the rest of this chapter if you are an application developer and you do not plan to write a printing dialog extension. You should read the rest of this chapter if
you plan to write a printing dialog extension for your application
you are a printer vendor
Tickets contain a number of individually accessible items that describe how to print a print job. Tickets do not contain the actual document data that is to be printed; the document data is in the spool file. Tickets created for a print job record various settings as the job progresses through the printing system. There are a variety of tickets used by the printing system, including the following:
job
page format
print settings
printer info
converter setup
paper info
list
PMTicketRef.A job ticket refers to the top-level ticket used for a print job. Although the job ticket may contain high-level information about the print job, the job ticket’s primary content consists of other tickets. Figure 2-2 shows a job ticket that contains page format, print settings, and printer info tickets. (The job ticket, like all tickets, is an opaque object. It may contain references to other tickets and not the actual ticket objects.)
The page format ticket describes the application’s drawing environment, including its resolution, scaling, orientation, paper size, and page size. The page format object used by an application is the analogue to the page format ticket. Page format data is typically saved by applications with the user’s document.
The print settings ticket contains the user’s Print dialog selections and any items set by the application to further refine the output produced on the printer. The print settings object used by an application is the analogue to the print settings ticket.
The printer info ticket is created by the printer module to describe features and settings of the destination printer. Information in this ticket is used by the printer module and the printing dialog extension associated with the printer module. The printer info ticket also describes the printer to the rest of the printing system. It includes such data as the printer’s name, color capability, native resolution, and all other device-specific features.
The converter setup ticket is used to convey control information from the printer module to the print job manager (which may add information to the ticket) and then to the converter. The converter setup ticket is constructed by the printer module to control the functioning of the converter and can set such things as resolution, band size, and pixel format. For example the printer module uses the converter setup ticket to configure the converter to generate raster data at a particular bit depth for a specified color space.
The paper info ticket contains a complete description for a single paper—Letter, Legal, A4, B5, and so forth—available from the printer module. The paper info ticket describes the paper sheet size and printable page area available to an application.
A list ticket contains a list of other tickets along with key-value pairs relevant to the list. Any type of ticket can be stored in the list. A list ticket is particularly handy to group paper info tickets. For example, if you are writing a printer module, you must add a list ticket to the printer info ticket to specify the paper sizes supported by your printer.
Data are always stored in tickets as key-value pairs using Core Foundation (CF) data types. Apple defines keys for the most common printing options and will likely add more keys in the future. Developers can define their own custom keys for those options not already defined in the application programming interface, but should do so only after checking the options defined by Apple’s keys. See Ticket Services Reference for a list of the current keys.
Ticket values can be any of the following Core Foundation data types:
Last updated: 2006-02-07
