Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!uokmax!servalan!rmtodd From: rmtodd@servalan.uucp (Richard Todd) Newsgroups: comp.unix.aux Subject: Re: A/UX 2.0 and Imagewriters non-features Message-ID: <1990Oct3.070956.2401@servalan.uucp> Date: 3 Oct 90 07:09:56 GMT References: <1990Sep28.224909.7440@servalan.uucp> <1990Oct3.022757.28724@ariel.unm.edu> Organization: Ministry of Silly Walks Lines: 57 einhorn@triton.unm.edu (E Drew Einhorn ADV.SCI.Inc) writes: >Has anybody attempted a port of Ghostscript to AUX? aux.writer2.0 available >for anon ftp on aux.support.apple.com provides a chooser device that looks >like a laserwriter but sends the postscript to a shell command. Ghostscript >could processes the postscript and compute a bit map. Then the only missing >piece would be a device driver to ship the bitmap to the printer. I have >a borrowed ImageWriter II that has to be returned and am thinking of buying >an HP DeskWriter (If I can get it to work w/ AUX). Funny you should mention that :-). Last night I downloaded Ghostscript from osu-cis, and tonight I've been working on compiling it. All I had to do was hack one of the files slightly (it was looking for struct tm in the wrong include file), and it compiled under gcc1.37.91 with no other changes. I've currently got it set up to work on the "X window" device and what I've tried seems to work like a charm, and do so a good deal faster than the version of RALpage I'd been using to preview PostScript output. (Haven't tried any MacOS-generated PS files, but I did do some ditroff output, a PS file from some mapmaking program a friend wanted me to preview for him, and various of the demo PS files that came with it, and it all seemed to work. Even groks the color commands in PostScript; check out the "escher.ps" demo file. Yow!) A friend of mine has an HP DeskWriter and A/UX; I think he said he didn't have any problems getting it going under A/UX. And, as it happens, one of the device drivers that comes with GhostScript is an HP DeskJet driver, which should be just right for you (DeskJet and DeskWriter do respond to the same control code set, I'm told). Obviously, the next order of business for me is to dig down into the sample Epson print driver for GhostScript and the DVI driver for the ImageWriter I/II and come up with a GhostScript driver for the IW II. When I get it done, I'll let you guys know (and probably post it here, too.) >Actually what Apple broke is the printer port. Things are supposed to work >ok if you put your printer on the modem port and the modem on the printer port It works ok with an ImageWriter II; I don't know about an LQ. Assuming the printer drivers aren't too different, it should work too. I might as well point out here another interesting "feature" of the software for non-Appletalk ImageWriters in MacOS-under-A/UX: when you first print from MacOS to that printer, the software apparently opens the appropriate tty device (i.e. /dev/tty0 for a printer on the "modem" port) and locks it, and doesn't close it after it finishes. What this means is that once you print something from the MacOS environment, you can't print anything with lpr (because lpd tries to open /dev/tty0 and fails) until such time as the original locking process (i.e. startmac{32,24}) closes that tty, which only happens when you logout from the Mac environment. Rather uncool, that. Ideally, of course, the ImageWriter, etc. drivers shouldn't be writing to the device directly, but instead allow one to specify a file (or pipe!) as a destination for the output, so you can have *all* printer I/O go through the lpr/lpd system. -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath