ADC Home > Reference Library > Technical Notes > Legacy Documents > Printing >
Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.
Current information on this Reference Library topic can be found here:
With the release of LaserWriter 5.0 and background printing, a few changes had to be made to the LaserWriter driver. Although these changes were transparent to most applications, some have had problems. Most of these problems are related to use of unsupported features. This Note details a partial list of the changes.
No Mo' Low
Because of the problems supporting both the high-level and low-level interfaces
in the background, the low-level interface is all but removed. Instead of the
low-level calls being executed by the device driver, the _
Version 5.x of the LaserWriter driver also contains a bug with the low-level interface. If an application which uses the low-level Printing Manager interface encounters an error during the course of the print job, the LaserWriter driver crashes before the application has a chance to see the error. Because the error occurs inside the driver, there is no way for an application to predict or work around this problem. The only solution to this problem is to use the high-level Printing Manager interface or to upgrade to version 6.0 or later of the LaserWriter driver which fixes this bug.
Are You Convertible?
Whereas the conversion of the low-level calls should be transparent, the conversion routines make some assumptions. The conversion routines require a context in which to operate; the Printing Manager maintains a certain state while executing commands, and the conversion routines need access to this state to perform the conversion. To provide this context, an application must have opened a document and a page. This requirement means that the original method of using the low-level interface, which is documented in Inside Macintosh, Volume II-164, no longer works, as in the following example:
Instead, an application should use the following:
This method provides the Printing Manager with the context it needs to convert the calls.
Really Unsupported Features
Sending data to the printer between the
A Little Less Control
Four of the six printer control calls originally supported by the LaserWriter driver have been discontinued due to lack of use and difficulty supporting with background printing. The four calls which follow were only supported by the LaserWriter driver and only documented in the LaserWriter Reference Manual.
In addition to these calls, the
If the bytes parameter is positive, the text passed to the call is sent
directly to the LaserWriter without conversion and interpreted as PostScript
instructions. This version of the call is still supported, but there is one
more problem. When an application first opens the low-level driver (via
To prevent this problem, the application must force a clip region to be sent to
the LaserWriter. The region is sent by the driver when it receives its first
drawing command. Unfortunately, the driver does not consider the
Fonts In An Application?
There are two problems when printing application fonts with the LaserWriter
driver. Application fonts are fonts that are stored in the resource
fork of the application's resource file rather than being stored in the System
file. The first problem occurs when the application font has the same name as
the application's resource file. If this is the true, the LaserWriter driver
incorrectly assumes that the application's resource file is a font file, and
closes it after using the font. To solve this problem, developers should make
sure the name of the application font (i.e., the
The second problem with application fonts only occurs when background printing is enabled. When a print job is performed in the background, the LaserWriter driver writes all of the data to be printed into a file (called a spool file) for printing at a later time by the PrintMonitor. Since the LaserWriter driver has no way of knowing when the file will actually be printed, it cannot assume that the application will still be open when the job is printed. This is a problem if the application contains application fonts that Print Monitor needs at print time. To solve this problem, the LaserWriter driver must determine whether the fonts needed by the application are resident in the System file or in the application file. If they are in the application file, the driver must copy them into the spool file so they are available to Print Monitor. This practice can lead to very large spool files, as well as a significant loss of performance when background printing is enabled. To solve these and other user interface problems related to application fonts, Apple strongly recommends that developers ship custom application fonts as suitcase files for the user to install in the System file.
Headin' For Trouble
There is a minor bug in version 5.0 of the LaserWriter driver that only affects
applications that parse the PostScript header downloaded by the driver with
each document. This header contains some PostScript comments that provide
information about the current job. One of these comments is
No Go With Zero
Some applications want to force a font to be downloaded to the LaserWriter without actually printing characters with the font. This can be done in three easy steps:
Some applications use
Inside Macintosh, Volumes II & V, The Printing Manager
LaserWriter Reference Manual
PostScript is a registered trademark of Adobe Systems Incorporated.