May 92 - PRINT HINTS
PRINT HINTS
TOP 10 PRINTING CRIMES
PETE ("LUKE") ALEXANDER
In this issue, we're going to take a slightly different tack. Instead of dealing with one printing hint,
we're going to give you ten. We'll take a look at the "Top 10 Printing Crimes" that I've seen during
my three and a half year adventure in Apple's Developer Technical Support Group. I'll start by
listing these crimes, and then I'll discuss the solution to each one.
Here's the list:
Loading PDEFs directly from within your application.
9. Poor memory management at print time.
8. Assuming the grafPort returned by PrOpenDoc is black and white.
7. Not saving and restoring the grafPort or resource file in your application's pIdle procedure.
6. Not using PrGeneral when you should to determine and set the resolution of the current device.
<
5. Not reading Macintosh Technical Note #91, "PicComments--The Real Deal," before you start
using PicComments in your application.
4. Opening the Printing Manager when your application starts up.
3. Mixing high-level and low-level printing calls.
2. Accessing private and unused fields in the print record.
1. Adding printing to your application two weeks before going final.
All of these crimes are very easy to avoid. Let's take a look at the solution to each one.
SOLUTIONS TO THE PRINTING CRIMES
10. Loading PDEFs directly from within your application. A PDEF is a printer
driver's CODE resource definition. Each printer driver contains multiple
PDEFs, which implement the various functions of the driver (such as displaying the Print dialogs,
opening the connection with the printer, and supporting PrGeneral). A few applications load and call
these PDEFs directly, probably because they feel this will improve printing performance. Instead,
this approach will usually cause serious compatibility problems and headaches for printer driver
developers. Also, it's very difficult for printing utilities (for example, utilities that count the number
of pages printed) to patch into printing if an application isn't using the printing trap (PrGlue).
Finally, this approach could cause some serious compatibility problems for users when a new printer
and its associated driver software are released.
Solution: The main function of the Printing Manager is to load the printer driver PDEFs in a device-
and driver-independent manner. Using the Printing Manager to load the PDEFs is the simplest and
most compatible method.
9. Poor memory management at print time. Poor memory management at print time will cause some interesting problems with various printer
drivers. Usually, some object in your document won't print or you'll receive a blank page. The
problem is that each printer driver available on the Macintosh requires a different amount of
memory; some require very little memory, while others require a lot. For example, the LaserWriter
SC is one of the piggier drivers. What's an application to do?
Solution: Since each printer driver uses a different amount of memory, there's not a magic amount of
memory that will always ensure the success of a print job. The best solution to this problem is to
unload all unnecessary code and data segments at print time. The more memory available, the better.
In addition to ensuring that printing will work OK, more memory can improve printing performance
significantly, which your users will thank you for.
8. Assuming the grafPort returned by PrOpenDoc is black and white. Yes, PrOpenDoc can return a color grafPort, if the printer driver you're using supports color.
Unfortunately, not all printer drivers are capable of returning a color grafPort. This feature caused
compatibility headaches for us when we released LaserWriter driver version 6.0, which was the first
printer driver from Apple that could return a color grafPort. Many applications assumed that the
grafPort it returned was black and white, and this assumption caused quite a few applications to die
when printing to LaserWriter driver 6.0. This assumption can also have some very ugly results if
your user is printing to a color printer and you're only sending black-and-white data.
Solution: A good rule of thumb when printing: never assume anything. Usually there are methods
available to enable your application to determine the environment it's in. Printing isn't any different;
in fact, this is probably even more important for printing. You should check the grafPort returned by
PrOpenDoc to see whether it's color or black and white: if the high bit in the rowBytes of the
grafPort is set, you have a color grafPort.
7. Not saving and restoring the grafPort or resource file in your application's pIdle procedure. Many applications install a pIdle procedure at print time. This procedure allows the application to
present the print job status to the user. This is a very good idea--but you must be a little defensive to
keep a printer driver happy.
Solution: When your application enters its pIdle procedure, you should save the current grafPort and
resource file (that is, the printer driver's). When you exit your pIdle procedure, you should restore
the grafPort and resource file back to the original. This is extremely important, because the printer
driver assumes that the current grafPort and resource file are always its own. If they're not, when you
exit your pIdle procedure you won't be drawing into the correct grafPort, and when the printer
driver makes the next Resource Manager call, it will have the wrong resource file. Technical Note
#294, "Me And My pIdle Proc (or how to let users know what's going on during print time . . . ),"
describes the details of creating and using a pIdle procedure within your application.
6. Not using PrGeneral when you should to determine and set the resolution of the current device. The PrGeneral trap allows a developer to determine the supported resolutions of the current printer,
and also to set the resolution, determine the page orientation selected by the user, and force draft
printing. Many developers who want resolution information don't use the power of this trap, but
instead use a device-dependent method, which isbad . PrGeneral allows you to determine the
resolution in a device-independent manner, so that you'll be able to print toall printers connected to
the Macintosh without knowing about the printer you're talking to. There are now over 130 printer
drivers available on the Macintosh. It would be a real shame if your application couldn't maximize its
output to a device just because you made a bad assumption.
Solution: This is a case where you can becompletely device independent in your print code without
sacrificing anything. You can obtain outstanding results if you use the PrGeneral trap correctly. Any
time you're interested in the available resolutions for the current printer, you should use the GetRsl
opcode supplied by PrGeneral. For details about getting and setting the resolution, see the "Meet
PrGeneral" article in Issue 3 ofdevelop. If you don't have the article handy, it's available on theDeveloper CD Series disc. Accompanying the article on the CD is an application named PrGeneralPlay
that contains complete sample code for PrGeneral. You should probably also take a look atInside
Macintosh Volume V, pages 410-416.
5. Not reading Macintosh Technical Note #91, "PicComments--The Real Deal," before you start
using PicComments in your application. Many developers have tried to use PicComments in their applications before understanding their
function, with very mixed results. If you don't follow the recommendations in Technical Note #91,
you'll definitely receive some undesirable results--especially if you don't match all "open" calls with a
"close" call.
Solution: Read Technical Note #91before you start using any PicComments in your application. This
Note has been rewritten with new pictures, sample code, and descriptions to help developers
properly use PicComments in their printing code. It will help
you avoid many of the pitfalls and misuses of PicComments. It's also helpful to look at pictures
generated by other applications, to see what they're doing.
4. Opening the Printing Manager when your application starts up. In the early Macintosh days, it was recommended that you always call PrOpen at application startup.
This hasn't been the recommendation for a long time. Why? When you open the Printing Manager,
it loads some of the printer driver's resources into memory. This means that less memory is available
for your application. However, the real problem is that other applications or DAs cannot print until
you close the Printing Manager, since the Printing Manager isnot reentrant. Unfortunately, there
isn't a reliable method for determining whether the Printing Manager is open, nor is there a method
for closing it if it's already open. This isn't much of a problem any more because the majority of
applications today no longer call PrOpen at startup.
Solution: Do not open the Printing Manager until you're ready to print or perform some other
printing-related task (for example, initializing a print record when your application starts up). You
should close the Printing Manager when the print job is complete or when you've accomplished the
task at hand. You should never allow a user to switch your application out with the Printing Manager
open (that is, never call WaitNextEvent between PrOpen and PrClose).
3. Mixing high-level and low-level printing calls. This is one of the classic printing problems. You shouldnever mix the high-level and low-level
printing calls. This approach will usually cause instant death at print time, because the high-level and
low-level calls do very similar things. One of the common mistakes is calling PrDrvrClose after
calling PrClose. Printer drivers are not designed to use both interfaces simultaneously.
Solution: In general, all applications should be using the high-level printing calls. Please follow the
advice in Technical Note #161, "A Printing Loop That Cares . . . , " which describes the use of the
high-level calls. Always match each "open" printing call with its corresponding "close" call. Also,
check the PrError function for a printing error before making the next printing call.
The only advantage gained by using the low-level calls would be when you're text streaming, which is
easier with those calls. Technical Note #192, "Surprises in LaserWriter 5.0 and Newer," describes
the use of the low-level interface.
As you might expect, there's a minor exception to this rule. If you've read the Printing Manager
chapter ofInside Macintosh Volume II, you may have noticed that the PrDrvrVers function is defined
in the "Low-Level Driver Access Routines" section (page 162). This function can also be used with
the high-level interface (it's theonly low-level call that can be called in the high-level interface). PrDrvrVers is very useful for determining the version of a printer driver, which will enable you to
work around bugs that may exist in a specific version of a printer driver.
2. Accessing private and unused fields in the print record. Many of the print record fields should not be accessed by an application because they're used by the
printer driver as storage locations, which means the information in themwill change during a print
job.
Solution: You should never use any information from fields in the print record that have "PT" at the
end of the field name. All of them have corresponding "public" fields in the print record for
application use. For example, you should use the information stored in rPage, and not rPagePT.
Printer drivers store some of their private information in the fields with "PT" at the end of the field
name. During printing, the values in these fields will change. Furthermore, different printer drivers
use these fields differently, so accessing one of them might work on one driver but not another. Use
the public fields!
1. Adding printing to your application two weeks before going final. This one might be a slight exaggeration, but it's definitely in the ballpark. Believe it or not, I've
talked to quite a few developers who have left printing as the last feature they add to their application
(or maybe next to last, just before Undo). This can cause some serious problems in your development
schedule.
Solution: There are a few pitfalls in printing, but they can be avoided if you start early in the design
phase of your application. My advice to avoid this problem is to start printing from your application
as soon as possible. When you have an early prototype running, send some output to the printer.
Usually you can tell very early if you'll have any problems.
One more thing: I created this list in order from the least printing crime to the worst. Actually, if you
commit any of the printing crimes mentioned, you'll probably receive some undesirable results with
various printers. I would suggest testing your application on at least one PostScript® printer and a
QuickDraw printer.
Finally, if we take a look out onto the documentation horizon, we can see something new peeking
through. What is it, you ask? It's the new and improvedInside Macintosh chapter on printing. Yes,
after years of waiting, it's finally coming. I believe you'll find the new printing chapter useful and
informative. It will unlock additional information about printing on the Macintosh.
- Inside Macintosh Volume V, Chapter 22, "The Printing Manager," pages 410-416 (Addison-Wesley,
1988).
- Inside Macintosh Volume II, Chapter 5, "The Printing Manager," page 162 (Addison-Wesley, 1985).
- "Meet PrGeneral, the Trap That Makes the Most of the Printing Manager," Pete "Luke" Alexander,develop Issue 3, July 1990.
- "Me And My pIdle Proc (or how to let users know what's going on during print time . . . )," Macintosh
Technical Note #294.
- "Surprises in LaserWriter 5.0 and Newer," Macintosh Technical Note #192.
- "A Printing Loop That Cares . . . ," Macintosh Technical Note #161.
- "PicComments--The Real Deal," Macintosh Technical Note #91.
PETE ("LUKE") ALEXANDER Inquiring minds want to know: Does Luke have a life beyond these weird Print Hints he dishes
out occasionally? The answer is a resounding YES! This happy hacker likes to keep his head in the clouds--literally. Theproud owner of an ASW-20 sailplane, Luke's other passion (besides working at Apple) is soaring 10,000 feet above
ground, while observing eagles, mountain goats, and wild horses in exotic outposts of California and Nevada. Luke has
the "funnest time" when he's gliding like a bird, suspended in time with the air rushing past him. For him, it's pure,
unparalleled excitement and enjoyment. *
Thanks to Dave Hersey and Scott "Zz" Zimmerman for reviewing this column. *