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.

REFERENCES

• 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. *