There are a number of ways the Mac OS X printing system can be used by your application or extended with software you create. Carbon, Cocoa, and BSD UNIX developers can add printing support to their applications. Carbon and Cocoa developers can add application-specific features to the Page Setup or Print dialog. Printer vendors can write printer modules to support their printers. They can also provide custom panes for the Print dialog to support printer-specific features. This chapter provides information on how to get started developing software that uses the Mac OS X printing system.
The Mac OS X printing system provides a collection of system software functions that you can use to print to any type of supported printer from Carbon, Cocoa, and BSD UNIX applications. This section provides information on what you need to do for each type of application to support printing.
The Carbon Printing Manager, by definition, consists of these header files:
PMApplication.h
PMCore.h
PMDefinitions.h
The header files are split between the Application Services and Carbon frameworks, and contain the functions and data types that support printing from an application, regardless of development environment (Carbon, Cocoa, or BSD UNIX). How your application accesses the Carbon Printing Manager depends on the development environment.
Carbon applications typically use functions and data types from all three header files, so these applications need to link to the Application Services and Carbon frameworks. Carbon applications can print in Mac OS 8 and 9 with existing printer drivers and in Mac OS X with new printer drivers. If you want to develop an application that can print in Mac OS 9 as well as Mac OS X, it must be a CFM application and you need to link to CarbonLib version 1.1 or later. CarbonLib is the Mac OS 9 extension that contains the Carbon Printing Manager API.
Before you implement printing in a Carbon application you should consult these documents:
After you install the Mac OS X Developer Tools CD, you can find sample code in this directory:
/Developers/Examples/Printing/App/
Cocoa applications use Cocoa objects and methods to support printing. Cocoa application link to the Application Kit which calls through to the Carbon Printing Manager. If you develop a Cocoa application, you can also call Carbon Printing Manager functions directly.
Cocoa developers can consult these documents for more information
Printing Programming Topics for Cocoa
Carbon Printing Manager Reference, if you plan to call this API directly.
After you install the Mac OS X Developer Tools CD, you can find sample code in this directory:
/Developers/Examples/AppKit/TextEdit/
Faceless BSD UNIX applications use functions and data types from PMCore.h and PMDefinitions.h, which are part of the Application Services framework, so this is the framework to which you need to link. BSD UNIX applications do not need the printing functions from the Carbon framework, as these functions support the printing dialog interface.
BSD UNIX developers can consult Carbon Printing Manager Reference for documentation on the functions and data types in PMCore.h and PMDefinitions.h.
In Mac OS X, Apple supplies Print and Page Setup dialogs that can be displayed to the user from Carbon and Cocoa applications. The panes in these dialogs contain the most common features needed by printers and applications, eliminating the need for most developers to provide printing dialogs.
You may need to write a printing dialog extension if you are a printer vendor and your printer provides features not supported in the Apple-provided Print dialog. Application developers may also need to support application features that are not supported in the Apple-provided Page Setup and Print dialogs.
Carbon application developers can extend a Print or Page Setup dialog by writing a printing dialog extension. For more information see these documents:
Ticket Services Reference
Cocoa application developers can extend a Print or Page Setup dialog by providing a custom view and using the setAccessoryView: method. For more information on adding an accessory view to a printing dialog, see Printing Programming Topics for Cocoa.
Printer vendors can extend the Print dialog by writing a printing dialog extension so the dialog supports printer-specific features when your printer is selected by the user. The custom pane you supply is displayed in the Print dialog regardless of whether the calling application is developed using Cocoa or Carbon. For more information see these documents
Ticket Services Reference
Printer vendors must supply a printer module for each printer or family of printers they want to support in Mac OS X. Printer modules replace the printer drivers used in Mac OS 8 and 9. A printer module is easier to write than a Mac OS 8 and 9 printer driver. A printer module does not need to take care of spooling or imaging. It needs only to receive data passed to it, in the format specified by the printer module, send the data to the printer using an I/O module, and handle any errors generated by the printer.
If you need to write a printer module, you should contact Apple Developer Technical Support and see these documents:
Ticket Services Reference
After you install the Mac OS X Developer Tools CD, you can find sample code in this directory:
/Developer/Examples/Printing/Printer/
It is possible for developers to write two other types of plug-ins that are used by the printing system—I/O modules and printer browser modules. An I/O module implements support for a printer’s transport type. Apple supplies a number of I/O modules for developers to use, so you typically do not need to write an I/O module. A printer browser module extends the Print Center application by adding support for users to set up printers that use printer connection methods such as USB and AppleTalk. Apple supplies printer browser modules that support USB, AppleTalk, and Directory Services, so in most cases you should not need to write a printer browser.
If you think you do need to write an I/O module or printer browser, you should contact Apple Developer Technical Support for more information. Before you write any code, check to see if Apple plans to revise an existing module or create a new one that addresses your needs. You should also plan to obsolete any custom module you create in the case that Apple revises its modules to meet your needs.
Last updated: 2006-02-07
