🚀 go-pugleaf

    With some help from Tim Lynch of Novell I was finally able to have some
limited success with printing to Novell Netware AppleTalk print queues, and
I thought some folks might be interested in what I found out. Tim writes:

    "All Mac jobs are Adobe Document Structuring Convention compliant to
some degree, meaning they start with "%!PS-Adobe-" and end with "%%EOF",
and have some other comments in them that may be of interest to print
spoolers.  The main difference between how CAP and the Mac work is that the
Mac sends all the job data and then assumes the printer will be able to
print it."

    "CAP and other print servers, on the other hand, send the job data and
then
wait for an EOF back from the printer before closing the PAP connection
so they can catch error conditions such as out of paper and PostScript
exceptions reliably.  ATPS currently only returns a PAP EOF at the end of
ADSC-
compliant jobs; ones that start with "%!PS-Adobe-" and end with "%%EOF"."

    So, armed with that new knowledge, I created a nice new ADSC compliant
Postscript file on my Mac by using the "print to a file" option available
in System 7, and ftp'd it to my Sun.  And, further armed with the knowledge
that comes from staring at a papif.c listing for a week, I also "setenv
DOACCT 0".  Papif, while smart enough not to bother trying to save
accounting information if you don't specify a log file, still tries to get
the pagecount from the printer, something that Netware queues don't seem to
like. Finally, it worked!

    Unfortunately, you can't count on all print jobs being ADSC compliant.
In this case, again with DOACCT set to false, although the job will still
be printed by the Netware queue, it causes papif to generate an idle
timeout. So now I have to either figure out how to hack papif to not look
for an EOF from the queue, or mess with the banner printing options to get
the appropriate PostScript stuff sent to the queue.  Any suggestions?

              Scott (traurig@ncavax.decnet.lockheed.com)