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?