tcianflo@nugipsy.UUCP (Tom Cianflone) (03/29/88)
Our normal mode of operation is to produce text using troff,
with TransScript doing the troff to PostScript translation.
Output is produced on our DataProducts 2665 laser printer.
(This is a PostScript printer.) We produce graphics on the Mac
and paste them in mechanically.
We are trying to complete a test case here to show that
the drawings we have on the Mac can indeed be printed on
our DataProducts 2665 laser printer. This test case will be
used to support our decision to purchase devps by Pipeline
Associates, which allows PostScript files to be sourced into
troff documents. For us, this is a chance to finally do
electronic cut & paste.
Unfortunately, we can't seem to get the Mac-generated PostScript
files to do anything but *print* on the printer. That is, the
printer looks at them as if they are something to print, not
something to *do*.
What we've done:
Saved two versions of a MacDraw drawing, one with clover-F,
one with clover-K.
Uplinked these files to UNIX, using SmartCom II and
xmodem.
On UNIX, we translated ASCII carriage returns to newlines.
This gave us two files, one with the prologue, one without, both
of which were usable with the UNIX editors. In the file with
the prologue, the vi editor says that one character is non-ASCII.
Haven't figured out the problem there yet.
In any case, we tried sending these files to the printer a few
different ways. Queueing them through lpr -Pps (ps is our local
id for the printer) just gets them printed out like text.
We tried this one: cat filename > /dev/tty25 (the printer port)
with no success (no output at all). We also tried cat-ing the
files and piping them to psif and pscomm, which are both low-level
filters used by TranScript. This clocked up cpu time but never
produced output or terminated.
Next we tried some suggestions from folks like, for instance,
adding this line at the beginning of the files:
serverdict begin 0 exitserver
And also adding the showpage command at the end. Still nothing.
I tried to include all the pertinent details here.
Anyone have any other suggestions? Remember, we are just trying
to show that we have all the pieces of the puzzle here already,
with the exception of devps to make life easy.
Thanks in advance...
--
=> Regards, Tom Cianflone @ Gould Computer Systems Division <=
=> ...!{uunet,sun,pur-ee,brl-smoke}!gould!tcianflone <=
=> ...!ihnp4!{codas,allegra}!novavax!gould!tcianflone <=
=> NOTE: Disregard header info. Email to above paths only. <=gae@osupyr.mast.ohio-state.edu (Gerald Edgar) (04/04/88)
In some cases, at least, the PS file must begin with the line
%!
Three characters, the third one being a SPACE. If your fiddling with
the file removed the space, you may get the file merely printed.
--
Gerald A. Edgar TS1871@OHSTVMA.bitnet
Department of Mathematics gae@osupyr.UUCP
The Ohio State University ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae
Columbus, OH 43210 70715,1324 CompuServetowfigh@phoenix.Princeton.EDU (Mark Towfigh) (04/04/88)
In article <993@nugipsy.UUCP> tcianflo@nugipsy.UUCP (Tom Cianflone) writes: > >Unfortunately, we can't seem to get the Mac-generated PostScript >files to do anything but *print* on the printer. That is, the >printer looks at them as if they are something to print, not >something to *do*. > >In any case, we tried sending these files to the printer a few >different ways. Queueing them through lpr -Pps (ps is our local >id for the printer) just gets them printed out like text. > [other attempts] I just had to solve almost the exact same problem yesterday! I was trying to filter the PostScript through their filters like pscomm and so on, very low-level things which you're not supposed to use anyway. Finally, after looking at every other man page reference, I decided to dig up the 4.2BSD Line Printer Spooling Manual. In this manual, it directed me to /etc/printcap, which I had looked at before. In my earlier looking at the filters, I had also checked out a few default PostScript files (like the one the system prints when there is an error). At the top of this, there was a %!, and I also found reference to this in the man page for TRANSCRIPT. Finally I understood the answer staring me in the face: I just had to put that extra line at the top. Now everything works fine, and yours should too. Boy, I hate little tricks like this. -- Mark Towfigh If there's one thing I like better than a bologna and whipped cream sandwich, it's honey and ketchup. ======================================================================= UUCP/Inet: towfigh@phoenix.princeton.edu BITNET: TOWFIGH@PUCC
lyndon@ncc.UUCP (Lyndon Nerenberg) (04/05/88)
> In some cases, at least, the PS file must begin with the line > %! > Three characters, the third one being a SPACE. If your fiddling with > the file removed the space, you may get the file merely printed. Are you sure about this? What about %!PS-Adobe which is a documented part of the encapsulation standard? I have noticed that some software (Ventura 1.0 under MS-DOS for one) outputs the header as ^D%! ... The idea being to force an end-of-job before your file. This really screwed us for the better part of a day - everytime we sent a Ventura created file via the UNIX spooler (lpd and pscomm) we would get raw PS source. It turns out pscomm.c was checking for "%!" to determine if it was a PS file. The fix was to add a check for "\04%!" ... -- lyndon {alberta,uunet}!ncc!lyndon lyndon%ncc@uunet.uu.net
cramer@optilink.UUCP (Clayton Cramer) (04/06/88)
> > In some cases, at least, the PS file must begin with the line > > %! > > Three characters, the third one being a SPACE. If your fiddling with > the file removed the space, you may get the file merely printed. > > -- > Gerald A. Edgar TS1871@OHSTVMA.bitnet > Department of Mathematics gae@osupyr.UUCP > The Ohio State University ...{akgua,gatech,ihnp4,ulysses}!cbosgd!osupyr!gae > Columbus, OH 43210 70715,1324 CompuServe I haven't found a PostScript printer yet that requires the %! header -- but there's a lot of other software out there that can get between your application and the printer in a network that does expect that header to identify a file as PostScript. (This sometimes presents annoying problems when you attempt to print out a PostScript file as ASCII). Clayton E. Cramer