jkrueger@dgis.UUCP (Jonathan Krueger) (01/09/88)
Has anyone tried this? I want to save postscript from a Mac application and print it on an Apple laserwriter that's connected to a Unix host. Seems like it oughta work, but it doesn't. What I've done: the application is MacDraw. I run it, open the document, start a print to the laserwriter, then type command-k's like mad. The driver saves the postscript to a file named PostScript in the folder that MacDraw is executing from. I use NSCA software over Kinetics hardware to transfer the file to the Unix host. It arrives as almost an ordinary text file; it has some characters from the extended character set. I noticed the copywrite symbol near the top, a control-d at the end, and a few others in the middle which Unix sees as bytes with the high bit set. But otherwise it looks like ordinary printable postscript representing my Macdrawing. The Apple laserwriter is connected to the Unix host using Adobe Transcript software and the Berkeley print spooling system. When I lpr the file, it ends up listing the Postscript code, not interpreting it. If I add the header line: %!PS-Adobe-1.0 (as Adobe's "enscript" generates) and lpr the file, nothing at all prints. The printer sits there and flashes its yellow light for a while, then the normal header page prints, but no output from the file, no drawing, nothing. The Mac is a Mac Plus, finder 5.3, 1024K, if that helps. The postscript is too large to post, but I'll gladly mail it to anyone interested. So, has anyone succeeded in printing Mac-generated postscript on postscript engines attached to Unix hosts as ordinary print devices? Is the Adobe software interfering, should I just cat it to /dev/lw? Do I need to perform a few edits on the postscript to remove appletalk or Mac laserwriter driver communications and leave in page description stuff? Does anyone out there do this all the time? Any ideas, suggestions, pointers, etc. are welcome and appreciated. -- Jon Krueger
dboyes@uoregon.UUCP (David Boyes) (01/11/88)
All Mac programs using the Laserwriter assume that the standard Apple LaserPrep file of PS macros has been downloaded to the Postscript device and has been allowed to install itself as permanently resident. I won't comment on the inherent stupidity of this approach, but if you append your file to a copy of the latest LaserPrep file and reset the printer after you are through (either by manual reset or the PS initialization sequence - cf. Inside Laserwriter or any reputable PS book) it should work fine. -- David Boyes | ARPA: 556%OREGON1.BITNET@CUNYVM.CUNY.EDU Systems Division | BITNET: 556@OREGON1 UO Computing Center | UUCP: dboyes@uoregon.UUCP 'How long d'ya think it'll be before just us oldtimers remember WISCVM?'
lamy@ai.toronto.edu (Jean-Francois Lamy) (01/12/88)
In article <1419@uoregon.UUCP> dboyes@drizzle.UUCP (David Boyes) writes:
# All Mac programs using the Laserwriter assume that the standard Apple
# LaserPrep file of PS macros has been downloaded to the Postscript
# device and has been allowed to install itself as permanently resident.
Permanent residence is not required. Simply comment out the line
which calls 0 exitserver in the LaserPrep prologue. The call to
setsccinteractive near the beginning should also be commented out (vintage
LaserWriters choke on it).
Non-Apple PostScript (e.g. QMS) printers may choke on the format of the
LaserPrep file created by versions 4.x (and maybe 5.x as well, haven't had the
opportunity to check): they seem to choke on the hexadecimal code for
smoothing. Maybe eexec or cleartomark behave differently. I have not tried
modifying the file to put the big hex strings on the stack and doing thee
eexec after that.
Has someone managed to get a QMS to print downloaded Macintosh files?
Jean-Francois Lamy lamy@ai.toronto.edu lamy@ai.toronto.cdn
AI Group, Dept of Computer Science uunet!ai.toronto.edu!lamy
University of Toronto lamy%ai.toronto.edu@relay.cs.net (arpa)
Toronto, Canada M5S 1A4 lamy@ai.utoronto, lamy@utorgpu (bitnet)tomwest@gpu.utcs.toronto.edu (Tom West) (01/12/88)
In article <1988Jan12.071823.1596@jarvis.csri.toronto.edu> lamy@ai.toronto.edu (Jean-Francois Lamy) writes: >Has someone managed to get a QMS to print downloaded Macintosh files? Yes, we (with the help of U of T Computing Service) here at Atmospheric Physics use the QMS for all types of LaserPrep files. We have a macro that figures out what version of the header the PS file needs and attaches the appropriate header. If you want to know what modification to the latest LaserPrep is needed, mail to me at any of the addresses below. -- Tom West BITNET: tomwest@utorgpu.bitnet, tomwest@gpu.utcs.utoronto Internet: tomwest@gpu.utcs.toronto.edu UUCP: tomwest@utgpu utzoo, yetti, harpo, mnetor \ cbosgd, deepthot, utoronto - !utgpu!tomwest ihnp4, lsuc, sfmin, vnr-vpa /
jon@iseesun.UUCP (Jonathan Chock) (01/14/88)
A similar situation, we create postscript on a IBM PC and send it to the SUN for printing. Many packages insert control-d's into their PS files. Control-d is the end of job character in postscript. It sounds like there's a control-d before the actual end of job, therefore it blinks a while and times out, producing nothing. To test this theory, use vi and remove the control characters, then use lpr to print. ohana
tj@gpu.utcs.toronto.edu (Terry Jones) (01/19/88)
Well there may be a couple of things. If it is complete in that LaserPrep is stuck on the beginning then you might be halfway there. BUT the real point I wanted to say is that %!PS-Adobe-1.0 is a bad line to stick on the front unless the file is REALLY encapsulated PostScript and can be reversed by transript's reversing filter. I doubt if this stuff can so the line should read %! That tells the spooler it is PostScript but not to try to reverse it. Also, other applications I have seen around use this line carelessly and it causes spooled printer users much grief. tj
tj@gpu.utcs.toronto.edu (Terry Jones) (01/19/88)
In article <1988Jan12.071823.1596@jarvis.csri.toronto.edu> lamy@ai.toronto.edu (Jean-Francois Lamy) writes: >Non-Apple PostScript (e.g. QMS) printers may choke on the format of the >LaserPrep file created by versions 4.x (and maybe 5.x as well, haven't had the >opportunity to check): they seem to choke on the hexadecimal code for >smoothing. Maybe eexec or cleartomark behave differently. I have not tried >modifying the file to put the big hex strings on the stack and doing thee >eexec after that. > >Has someone managed to get a QMS to print downloaded Macintosh files? Like we work across the street from each other but talk over miles of wire... From what I have seen the problem with the QMS is what it HAS and not what it doesn't have. It has a smoothing function builtin that is executed if it exists and the hex downloaded smoothing routine is flushed. Now the problem is that it looks for the control-d to determine where to stop flushing. Now control-d's in the middle of files cause transcript grief. (BUG, are you listening Adobe) but I found the simple solution is to always use the hex code for smoothing. I know I should use the built in, but I wanted a LaserPrep that would work with all printers, we use QMS and ALW's. All I did was edit the LaserPrep and change the place where it checks for the existance if smooth and one other function to always return the value needed so the downloaded code would get executed. I did this for someone at another site actually since I rarely send Mac stuff myself and he says it works great. I tried it here and it worked on OLD ALW's, new ones, linotype and QMS PS devices. If more people need the exact changes send mail and I will post. tj
tj@gpu.utcs.toronto.edu (Terry Jones) (01/19/88)
Thanks to Tom West for the credit... I hadn't read all the replies before I replied and it was his site I made the mods for. SInce Tom is willing and able to offer the fix, I will let him!! tj