Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale!quasi-eli!cs.yale.edu!!majumdar-aloke From: majumdar-aloke@CS.Yale.Edu (aloke majumdar) Newsgroups: comp.protocols.appletalk Subject: Re: LaserWriter 7.0 vs. LaserWriter 6.1 vs. lwsrv Message-ID: Date: 19 May 91 17:23:53 GMT References: <462@goblin.ntg.com> Sender: news@cs.yale.edu (Usenet News) Reply-To: majumdar@cs.yale.edu Organization: Computer Science, Yale University, New Haven, CT 06520-2158 Lines: 34 In-Reply-To: dplatt@ntg.com's message of 15 May 91 22: 57:17 GMT Nntp-Posting-Host: garnet.systemsx.cs.yale.edu Dave> Sigh again. I'm rapidly coming to the conclusion that lwsrv's handling Dave> of the LaserPrep file... which was both necessary and sufficient for the Dave> LaserWriter 5.2 driver and its earlier cousins... is _neither_ necessary Dave> nor workable in the New Era of non-persistent prep-files. Dave> It's no longer really necessary to strip out the prep-file transmitted Dave> by the LaserWriter driver, hand-edit it to remove the "exitserver" Dave> coding, and automagically reinsert the edited version on-the-fly when Dave> spooling a job. There's no longer any "exitserver" code in the main Dave> prep-file... and we apparently cannot depend upon Apple to disambiguate Dave> different versions of the prep-file by changing the revision number when Dave> compatibility is lost. Dave> So... I think I'll see if I can work up a new set of patches to lwsrv, Dave> which will simply allow newer versions of AppleDict (>= 71) to pass Dave> through unmodified. I've been using lwsrv to spool Mac Output to a DEC LPS40. The standard AppleDict from Apple will not work (the DEC print queue flushes it). I have to use a modified AppleDict (with the same version number) which gets inserted into the print job in place of the real McCoy. This is done without needing to change anything in the user's configuration. As you can readily see, this is only possible because lwsrv has the option of inserting a customized procset masquerading as the real one. If the procsets are no longer stored on the spooler side, this very desirable feature of lwsrv will be lost. So while I see the need for some kind of change in the way lwsrv works, I wouldn't like to lose the option of spooler-cached procsets. Sorry I can't add anything more constructive at this point. Aloke Majumdar