coolidge@cs.uiuc.edu (John Coolidge) (04/08/91)
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? For the moment we've dropped back to the drivers from 6.0.5 (LaserWriter 5.2) and things work as expected; however, we'd really rather use the current drivers (especially the 7.0 driver, which is quite spiffy...). --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.
dplatt@ntg.uucp (Dave Platt) (04/09/91)
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
dplatt@ntg.uucp (Dave Platt) (04/10/91)
I've managed to modify lwsrv to work with the 6.1 LaserWriter driver.
The changes are modest... a few lines to simple.c, and a small amount of
hand-editing to the uploaded prep file.
I found at least three separate problems which contributed to the
inability of lwsrv to handle LaserWriter 6.1 output:
- Apple has two prepfiles which announce themselves with the same
AppleDict version number. One is a persistent "exitserver" job, the
other is not.
- When the LaserWriter 6.1 driver transmits the first (persistent) prep
file, it sends an EOF without sending an %%EndProcSet comment first.
- When lwsrv sees the EOF in the persistent procset, it closes the file
to which it was capturing the procset. However, it fails to zero out
the variable which was holding the procset file descriptor. Hence,
when the LaserWriter driver tries to send up the "real" AppleDict 71,
lwsrv mistakenly believes that a procset was already being uploaded,
and flushes the new one. It then prepends the smaller "persistent"
procset rather than the "real" one, and the print job fails due to
missing dictionary entries.
In order to fix these problems and make lwsrv compatible with the
LaserWriter 6.1 driver, you'll need to apply the following patches to
lwsrv and follow a simple procedure.
*** simple.c.orig Tue Apr 9 16:34:36 1991
--- simple.c Tue Apr 9 17:03:05 1991
***************
*** 511,519 ****
echo = FALSE;
stripspaces(ts); /* clear off extra spaces */
if ((dl = GetProcSet(ts)) != NULL) {
! fprintf(stderr, "lwsrv: simple: procset already known\n");
break;
}
#ifdef xenix5
sprintf(tmpstr, "%s/Found.%d",dictdir,time(0));
#else xenix5
--- 511,520 ----
echo = FALSE;
stripspaces(ts); /* clear off extra spaces */
if ((dl = GetProcSet(ts)) != NULL) {
! fprintf(stderr, "lwsrv: simple: procset %s already known\n", ts);
break;
}
+ sleep(1); /* raise odds of unique timestamp */
#ifdef xenix5
sprintf(tmpstr, "%s/Found.%d",dictdir,time(0));
#else xenix5
***************
*** 649,654 ****
--- 650,656 ----
}
if (procsetfile) {
fclose(procsetfile);
+ procsetfile = NULL;
if (dlnew) {
unlink(dlnew->ad_fn);
free(dlnew->ad_fn); /* free fn */
Now, for the procedure:
- mkdir /tmp/procsets or some other temporary location. Make sure that
this directory is empty.
- Start up lwsrv. Run it in single-fork mode (-S), debugging the NBP
packets (-dn), giving it a dummy printer name to proxy (-n test),
pointing it to a real LaserWriter (-p MyPrinterName), specifying the
usual font-dictionary file, running in trace mode (-t /tmp/tracefile)
and pointing at the temporary procsets directory (-a /tmp/procsets).
- On a Mac which has the LaserWriter 6.1 driver installed, fire up the
Chooser, select the LaserWriter 6.1 driver, and select the "test"
printer. Close the Chooser.
- Open up a Finder window and do a "Print directory". On your Unix
machine, lwsrv should report that it's uploading the procset
"(AppleDict md)" 71 0. It should actually perform the upload twice,
into two different FoundProcSet files. It will then receive, and
dump to the trace file, the Finder's directory output.
- After the job is finished uploading, hit control-C to terminate
lwsrv.
- Edit the first of the two FoundProcSet files in /tmp/procsets. Add
the word "persistent" (or anything else, actually) at the end of the
first (%%BeginProcSet) line, after the "71 0" identifier. Add a new
line immediately after the %%BeginProcSet line:
0 serverdict begin exitserver
thus replacing the exitserver which lwsrv had removed.
- Move the two FoundProcSet files from /tmp/procsets into your real
procset directory. Kill and then restart each of your real lwsrv
processes.
This should do the trick. When lwsrv starts up, it will see the two
6.1-based procsets, but it won't confuse the two (because you've changed
the %%BeginProcSet line in the persistent procset). You can arrange to
download the persistent procset to your printers periodically, so that
it's installed whenever a printer reboots.
This same approach should, I think, work OK with the LaserWriter drivers
which come with System 7.0. I haven't tried it yet.
In my brief experiments, I've been able to spool jobs from a 5.2 and 6.1
LaserWriter driver to the same lwsrv process without any problems
whatsoever... they spooled OK and printed OK (on a printer which had
already been prepped by a Mac running LaserWriter 5.2).
--
Dave Platt VOICE: (415) 813-8917
UUCP: ...apple!ntg!dplatt
USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303