PRINT HINTS WITH LUKE & ZZ
ZZ speaks
Once upon a time, in an engineering department far, far away, the great implementors (GIs) ran
across a problem with their Frankensteinian monster. They had designed and built a powerful beast.
A beast that had traveled great distances into unknown territories, and that had cut many new paths
in the hot lead jungle. Many spoke of the creation, and it had become well known and respected in
many lands and platforms. But the complexity that only the great implementors had dared to conceive
was being challenged by the great hackers of the land. Many of them had conquered the secrets of
the beast, and shared the knowledge of the great implementors. Soon, even mortal hackers would be
able to control the beast. This would not do. . .
The GIs traveled far to find the infamous "field workers." They had already given the GIs the gift
of dynamic, incomprehensible data structures, and the GIs were hopeful that they could provide
something more. They could not. . .
At last, on their return from the field, they ran across a court jester. Like all good jesters, he was
trying hard to find some fun. He tried to get the
GIs to play a game with him. He tried Monopoly, Pictionary, even checkers, but the GIs were not
interested (he did notice a little glimmer when he mentioned thermonuclear war, but not enough to
be important). As a last resort, he finally said, "Pick a number." Suddenly, the great gods of
arbitration came down on the GIs like a 5-ton weight. "Pick
a number!" one of them shouted. "It's beautiful!" laughed another one. And soon they were off to
the lab to implement their new discovery.
This folks, is the not-based-on-a-true-story story of the constant named iPfMaxPgs. This constant
is part of the Printing Manager, and limits the number of pages that can be spooled (that is,
written to disk) in one print job. In the old days, when even engineers at Apple were using floppy
drives, the Print Shop came to the conclusion that there should be a limit on the number of pages
you could print in a single job. If not, the user could easily use up all the disk space on the boot
disk, which at the time, led to other, even more interesting problems. The decision to limit the
number of pages was quickly followed by a decision to use the court jester's advice and "pick a
number." The magic number is 128, and is referenced by the constant iPfMaxPgs.
So now, you are printing your favorite report, all 130 pages of it, and just to annoy your
neighbors, you're printing to your ImageWriter II in Best mode. You've placed the printer next to
the window in the bathroom where the acoustics
are especially outgoing, and the window is open for the extra cooling effect (at least, that's what
you told the neighbors). As the head rips across the bottom of page 128 like nails across the
chalkboard, you are suddenly greeted with a Printing Manager error code. Sure, your neighbors
are happy, but you still have two pages to go. You frantically dig for that suicide prevention
number (that your neighbors have obviously borrowed), but decide instead that printing more than
128 pages in one job would be a great way to get new neighbors.
To print jobs longer than 128 pages, you simply treat them like multiple jobs, printing each set of
128 pages just like the first set. To make this even simpler, it would be nice if there was one line
of code that told you when to close the current document and open the new one. Welcome to the
MOD squad (or the % Club for you C dudes).
The MOD instruction is very useful for tracking sets
of things, like the number of pages in a print job. Most people that have implemented a Macintosh
printing loop (you can spot them by the gray hair and growing forehead) use some kind of page
loop.
The following code fragments will show the flow of control using the MOD operator. The parameters
of the Toolbox routines have been omitted for simplicity.
Before you knew enough words to type 128-page documents, you used to have a print loop that
figured out how many pages you had to print and then printed them one at a time.
This works well for bothering neighbors, but you'll never get any For Sale signs with this
technique. To print jobs larger than 128 pages, you need to call PrOpenDoc/PrCloseDocwithin the FOR loop.
Whenever you reach 128 pages, you need to call PrCloseDoc to close
the current document, and then PrPicFile to despool the (now full) spool file. Once this is
done, a new document is opened, and everything continues as before.
FOR pageIndex := firstPage TO kNumberOfPages - 1 DO
BEGIN
(* If we are on page number 128,
we need to close and reopen the document *)
IF (pageIndex - firstPage) MOD iPFMaxPgs = 0 THEN
BEGIN
(* Make sure there is a document open before
calling PrCloseDoc! i.e. if this is the first
page, don't call PrCloseDoc... *)
IF pageIndex <> firstPage THEN
BEGIN
PrCloseDoc(...);
PrPicFile(...);
END;
(* Now open a fresh, 128 page spool file. *)
PrOpenDoc(...);
END;
(* Call PrOpenPage/PrClosePage for each page of the document. *)
PrOpenPage(...);
PrintAPage(...);
PrClosePage(...);
END;
(* Finally, close the document and despool the spool file.*)
PrCloseDoc(...);
PrPicFile(...);
.
.
.
Pretty straightforward, but you'd be surprised how many developers the great implementors have
caught with this one. Using the above method, you can safely print large documents on any
device, without having to worry about overflowing the spool file. As for your neighbors, you could
always put a Pause/Continue button in your Printing Status dialog, but then, where's the fun in
that?
