Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!ntg!dplatt
From: dplatt@ntg.uucp (Dave Platt)
Newsgroups: comp.protocols.appletalk
Subject: Re: CAP and LaserWriter 6.1/7.0?
Message-ID: <49@goblin.ntg.uucp>
Date: 9 Apr 91 00:05:04 GMT
References: <1991Apr8.033857.4061@m.cs.uiuc.edu>
Reply-To: dplatt@ntg.UUCP (Dave Platt)
Organization: New Technologies Group, Inc.  Palo Alto CA
Lines: 51

In article <1991Apr8.033857.4061@m.cs.uiuc.edu> coolidge@cs.uiuc.edu writes:
>We've been printing happily with CAP (5.0, A/UX native AppleTalk talking
>EtherTalk) for quite a while with older LaserWriter drivers. Now that
>6.1 and 7.0 don't use LaserPrep and do lots of extra negotiation (or so
>it seems), printing seems to be completely broken (all we get is header
>pages). Has anyone gotten printing to work with CAP and the recent
>drivers? If not, is anyone working on a solution?

Well, I'm looking at it here (for CAP 6.0).  No solution yet, but I
think I understand the problem.

The problem is that the 6.1 drivers have split the AppleDict prep stuff
into two parts.  The first part is a small set of persistent
(exitserver-style) patches which are downloaded to the printer... it
looks as if there's some binary-code patching occurring on the
LaserWriter II NT.

The second part is the full QuickDraw-on-top-of-PostScript "md"
dictionary... it's nonpersistent (not in an exitserver) and is normally
prepended to each job.

Unfortunately, both of these sets of procs include an identical
'%%BeginProcSet: "(AppleDict md)" 71 0' header.  This appears to confuse
lwsrv most seriously!  It seems that lwsrv accepts, edits, and stores
the first procset in the usual fashion (storing it in the procsets
directory).  When the job itself is spooled, it appears that lwsrv sees
the second (in-line, nonpersistent) %%BeginProcSet command, and either
tells the LaserWriter driver not to send it, or absorbs it in-line and
drops it on the floor (I'm not sure which).

The net effect is that the PostScript job from the Mac is sent to the
printer with an exitserver-less version of the patches (procset 1) but
without a copy of the nonpersistent, in-line dictionary (procset 2).

One possible fix would be to add some AppleDict-version-specific code
for versions 71 and above... it would allow the first (patch-file)
dictionary to be uploaded unchanged (with its "exitserver") intact, byt
would prevent the second (in-line) procset to pass through the job
unmodified.

Another way to get around the problem would be to force a full
trace-file upload of a job (this captures both procsets, in-line), then
extract the nonpersistent procset and use it to overwrite the one that
lwsrv had captured.

I'll fiddle more later.

-- 
Dave Platt                                                VOICE: (415) 813-8917
                    UUCP: ...apple!ntg!dplatt
 USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303