In my last column (indevelop Issue 10), I talked about the "Top 10 Printing Crimes"
that would cause you and your application serious headaches during print time. Here
I'll list the "Top 10 Printing Misdemeanors." A printing misdemeanor will cause
minor to major printing problems on different devices. Usually, you'll be able to get
output onto a page, but it won't necessarily be what you want or where you want it.
Here's the list:
Most of these misdemeanors are easily avoided if you plan ahead. Let's take a look at the
problems and the solution to each one.
SOLUTIONS TO THE MISDEMEANORS
10. Using CopyMask and CopyDeepMask with the LaserWriter.
It's not possible to directly print to a LaserWriter an image that was created with
CopyMask or CopyDeepMask, because these calls aren't saved in pictures and they don't
go through the stdBits QuickDraw bottleneck. The image's data must be recorded in the
picture or go through the stdBits bottleneck in order for the LaserWriter driver to be
able to image the data on the printer.
Solution: You can create your image in an off-screen world using CopyMask and
CopyDeepMask to your heart's content. When you're ready to print your image,
CopyBits it directly to the LaserWriter's grafPort using srcCopy.
9. Using the obsolete spool-a-page, print-a-page method.
There are still a few applications using the spool-a-page, print-a-page method of
printing a document. This approach is no longer required unless you're printing from
a Macintosh that doesn't have a hard drive. Otherwise, it's a bad idea; it has major
drawbacks in the areas of speed and user happiness.
The idea of this method was to print each page of a document as a separate job. This was
required in the early Macintosh days because disk space was at a premium. It
prevented a document from filling up the entire disk and never printing a page. But in
this age of hard disks, it's no longer needed.
Opening and closing the Printing Manager for each page could result in a serious speed
penalty. And it could make your users very unhappy when printing to a shared
printer; it's possible to have another user grab the printer before you do, thereby
intermixing your pages with theirs.
Solution: Don't use the spool-a-page, print-a-page technique. Instead, use the method
described in the Technical Note "A Printing Loop That Cares . . .".
8. Not being very careful when using SetOrigin with the LaserWriter.
If you're using SetOrigin to change the coordinate system when sending direct
PostScriptTMcode to the LaserWriter, you'll run into trouble when printing in the
foreground versus the background.
The PostScript LaserWriter drivers 4.0 through 5.2 handle SetOrigin differently
when background printing is enabled.
In LaserWriter drivers 6.0 and later, the call to SetOrigin is a problem only on the
first page that's spooled. After the first page, the driver looks at the grafPort's
coordinates and then records the SetOrigin information correctly by inserting a
picture comment into the spool file. This enables PrintMonitor to realize when the
origin changes. Unfortunately, the driver never records the changes produced by a
SetOrigin call when it's in the stdBits QuickDraw bottleneck.
Solution: In general, using SetOrigin doesn't buy you much, and it can get you in a lot of
trouble. There are still a few printer drivers that don't handle the call correctly.
Avoid using SetOrigin if possible.
If you use SetOrigin when sending direct PostScript code, use the techniques described
in the Technical Note "Position-Independent PostScript" to ensure that all the
PostScript code your application creates is position independent. To get the
LaserWriter driver to realize as soon as possible that you've changed the coordinate
system, you can send the following code:
PicComment (PostScriptBegin, 0, nil); PicComment (PostScriptEnd, 0, nil);
This is a little weird, but it works because the two PicComment calls go through the
stdBits QuickDraw bottleneck, which is where the driver checks and updates the
coordinate system as required.
7. Creating pictures while the Printing Manager is open.
Some applications use a picture to collect all their QuickDraw objects before sending
them on to the printer. This approach is OK unless the Printing Manager has already
been opened by a call to PrOpen. The most noticeable problems are memory use and
floating picture comments.
The memory problem can be very evident if you're printing to a printer driver that
requires a lot of memory. Between your memory use and the printer driver's, there
might not be enough memory available to meet everyone's appetite. Remember, there
isn't a magical amount of memory that will guarantee that your application will print
successfully.
The other significant problem you might encounter is floating picture comments. When
this occurs, the picture comments sent by your application will be recorded out of
order, which will usually cause your image to print its objects out of order.
Solution: Read the Technical Note "Pictures and the Printing Manager" before you start
to use pictures at print time. Better yet, don't create a picture when the Printing
Manager is open.
6. Not having all your data ready for the Printing Manager when you
open it.
There aren't too many things you can do to speed up printing, but having data ready for
the Printing Manager when you open it is one of them. If you open the Printing
Manager and then go off to collect data you want to print, your printing time could
increase dramatically. You also run the risk of timing out the print job because you
don't send data to a networked printer fast enough or your print job takes too long to
complete.
Solution: When you open the Printing Manager, have all your data collected and ready
to send to the printer. Make sure the data is formatted for the current printer (see the
next misdemeanor for additional details).
If your application needs to perform a lot of data collection or preparation (as would a
database application), consider spooling all your information to disk as pictures. This
is especially useful when you don't know how long it will take to gather the data for a
particular page. To use this approach, you would open up a file and write out each page
as a picture (as the Printing Manager does), spool everything to disk, and then send
the pictures to the printer driver. Printing will be really fast! But be sure not to
commit misdemeanor 7 above, and note that this should not be the only way your
application prints; since you may not have enough disk space, you should make it an
option in a Preferences or Print dialog.
Having your data ready to go when you open the Printing Manager ensures that you'll
print as fast as possible and avoid timeout problems. And it will make your application
a friendly networked printer user, compared to grabbing the printer on the network
and hogging it while your application collects data.
5. Making assumptions about the imageable area.
Some applications make assumptions about the imageable area (the page rectangle) at
print time. This can cause some serious speed and clipping problems. If any
part of your image (which may contain text, QuickDraw objects, bitmaps, or
pixMaps) falls outside the page rectangle, the printer driver will need to clip it.
This will slow down the printing process and you won't get the output you want.
The imageable area for each printer is slightly different; this is actually a good thing,
since it allows the printer driver to take full advantage of the printer's
capabilities.
About half of the printing game is reformatting your image to work for the currently
selected printer. This problem is most noticeable when you print to a film recorder
an image that was set up for a LaserWriter. If you don't reformat the image, you won't
get the results you want; because of the higher resolution of the film recorder (1500
versus 300 dpi), you'll get a micro-image and you'll waste film. Also, most film
recorders print only in landscape orientation.
Solution: Since each printer has a slightly different imageable area, you should format
your image to this area. Before sending your data to the printer, you should format it
to rPage, the page rectangle for the current printer. rPage lives in the TPrInfo record
within the print record. However, becareful; as mentioned in the previous
misdemeanor, you should have all your data ready to send (including all formatting)
before opening the Printing Manager. Open the Printing Manager, get the dimension
for rPage, close the Printing Manager, format your data, open the Printing Manager
again, and print.
One approach for saving your data within your application to help you format it at
print time is to specify the location of each object on the page as a percentage of
distance (as opposed to pixels). For example, you could specify an object to be 10%
from the top and left margins. You would then always be able to place the object in the
correct position for all printers no matter what the resolution.
4. Using variables from Laser Prep (that is, md).
Using operators from the LaserWriter driver's dictionarymd is a classic way of
causing your application compatibility problems when a new LaserWriter
driver is released. Some developers do this to achieve additional PostScript
functionality at print time. The problem is that when Apple releases a new
LaserWriter driver it usually changes a few of the operators inmd. This will then
break code that depends onmd. It's an even bigger problem if you save this
information in pictures. When a new LaserWriter driver is released, none of these
pictures created by your users will be able to be printed.
Solution: Don't use any of the operators defined withinmd in your printing code. This
has been around for a long time as a compatibility issue; take a look at the Technical
Note "Using Laser Prep Routines" for the historical data.
If you decide to jump off the cliff and use operators inmd, you owe it to your users to
check the existence of an operator before you use it. This piece of PostScript code will
do the trick:
userdict /md known
{
md /bu known {myBU} if
} if
In this example, we're checking for the existence ofbu before we replace it with our
newly defined operator,myBU. If thebu operator didn't exist, we'd do the right thing
(that is, we'd still be able to print).
3. Checking wDev for the wrong reasons.
The printer type (such as LaserWriter or StyleWriter) is stored as an unsigned char
in the high byte of the print record's wDev field (in the TPrStl record). Each
printer driver has a unique wDev, and there are now over 142 wDevs in the world.
That's quite a few printers available for your application to print to.
If you're checking wDev to see which type of printer you're talking to, you could end
up very disappointed. Relying on wDev to make decisions at print time makes your
application completely device dependent. What do you do when you get a wDev you don't
know about? You have to make assumptions about the printer, and if you make a bad
decision, you won't get the output you expect. This isn't fair to your users; they
should be able to print to any printer that's connected to the Macintosh.
When we were developing the StyleWriter printer, we had some serious compatibility
problems with a few of the major applications. They assumed that any device with a
resolution greater than 300 dpi must be a PostScript printer. They sent only
PostScript code to the StyleWriter, which didn't work out too well, since of course the
StyleWriter doesn't understand PostScript.
Solution: Don't check wDev, with a couple of exceptions. One exception is that you
should check wDev and the printer driver version if you need to work around a bug in
the printer driver. This is the only method available to determine whether you're
dealing with a particular printer driver. Checking the driver version by calling
PrDrvrVers is important, because when the bug is fixed, you can remove your fix and
let the driver do the work. Another exception is that you can check wDev after you've
created a valid print handle (by calling PrintDefault) to see if the user has changed the
printer type (for example, a LaserWriter to a StyleWriter) via the Chooser. In any
case, be sure that when you do check wDev, you check it as an unsigned char value.
2. Accessing print record fields that are used internally.
You may notice that this is similar to the number 2 printing crime in the Print Hints
column in Issue 10. There I emphasized the crime of accessing private ("PT")
fields that you may come across when prowling around in the print record. Also
likely to cause inconsistent results is the misdemeanor of accessing other fields
in the print record that are used internally (or unused). To make this even
clearer, I'll tell you just what print record fields youcan read and write.
The print record is chock full of information. It's an application's playground during
printing. It's also used by printer drivers to hold information about the current print
job. Since each printer has slightly different needs, each one uses these fields
differently. The public API documented inInside Macintosh is the same, but the rest of
the print record is free domain for the printer driver to use as it sees fit.
Setting a field that the printer driver doesn't expect you to touch can cause big
problems for your application. This is one of the reasons why printer drivers have
compatibility problems when they're being developed, and why they take so long to
create.
Solution: Don't set any fields in the print record besides iLstPage, iFstPage, pIdleProc,
pFileName, and iFileVol. If you do, you're running a serious compatibility risk with
new printer drivers and printers you don't have access to during your test cycle. See
the Technical Note "A Printing Loop That Cares . . ." for details about setting and using
iLstPage and iFstPage, and the Technical Note "Me and My pIdle Proc (or how to let
users know what's going on during print time . . .)" for details about setting pIdleProc.
Don't read any fields in the print record besides the ones you can set and the fields
rPage, rPaper, iCopies, iVRes, iHRes, bjDocLoop, and bFileVers. (You can also read
the TPrStatus record returned by prPicFile.)
1. Adding printing to your application four weeks before going final.
This too is similar to a printing crime in Print Hints in Issue 10 -- but there has
been a change, to four weeks instead of two. I can't emphasize this enough. Since my
last column, a couple of developers have come to us with major printing problems
and a shipping deadline only a few weeks away. They had just started to add printing
to their applications.
Solution: Designing printing at the beginning -- not the end! -- of your application's
development cycle is the solution to most of your printing headaches. Printing
performance can make or break an application. You should convince the right people in
your organization that printing is just as important as any other feature. There are a
few pitfalls in the current printing architecture, but most of these problems can be
avoided without a lot of work -- if you design printing into your application from the
start.
So please, stay out of trouble and avoid the printing crimes and misdemeanors. You'll
be a happy printing developer and your users will also be delighted.
PETE ("LUKE") ALEXANDERLuke's latest adventure was landing his sailplane close
to the edge of the earth (there's an actual sign, near Gerlach, north of Reno, that reads
"The Edge of the Earth, 8 miles -- Planet X"). Not only is this in the middle of
nowhere, but rumor has it that Gerlach is the home of the best ravioli in Nevada. Luke
and his friends didn't locate the ravioli, but as a consolation prize they stumbled onto
Planet X instead (and Planets Y and Z, all art galleries, run by a slow-motion hippie
who will reluctantly take MasterCard, if you have all year). The edge of the earth did
deliver some great camping under the stars, and real cool satellite watching. *
Thanks to Hugo Ayala, Dave Hersey, and Scott ("Zz") Zimmerman for reviewing this
column, and to Ana Wilczynski for the column idea.*