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?