Path: utzoo!utgpu!watmath!att!dptg!rutgers!tut.cis.ohio-state.edu!ucbvax!ANDREW.CMU.EDU!jaap+ From: jaap+@ANDREW.CMU.EDU (Jaap Akkerhuis) Newsgroups: comp.soft-sys.andrew Subject: Re: ez -> Postscript Message-ID:Date: 8 Aug 89 16:21:57 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 90 > Excerpts from internet.info-andrew: 8-Aug-89 ez -> Postscript Nathaniel > Borenstein@thu (742+1) > How can I translate a complex ez document to Postscript? I know it can > be done, because I know that that's how they print. But I've tried all > sorts of variants and switches using ezprint, ditroff, and the like, > with no luck. Surely there's some magic incantation I can use that will > allow me to capture the Postscript without sending it to the printer? > Thanks in advance for your help. -- Nathaniel It is always interesting to see how little people at cmu know about the way their own programs print [An Andrew ToolKit view (fnotev) was included here, but could not be displayed.]. Anyway, here is an overview of how it is supposed to work. The ATK datastream is converted into a troff input stream. If you use eq, it is also puts in eqn input, so in that case you have to use that as well. If you have rasters or zip as well, then this is turned into PostScript. So the basic idea is that all this mess is send to a PostScript printer by ezprint. To break down what ezprint does you can give it the -t option, then it will put the (hybrid) troff stream on standard output and you can do all the convertions by hand. This is also useful to see where what goes wrong. If you have printing problems, I suggest to do the following: ezprint -t file > file.tr # This will give you the raw datastream eqn < file.tr > file.eqn # eqn at work in case you use eq Note that depending on the version of eqn you have to give an option (mostly -Tdevice), that will do some adjustments for the device. Also, eqn could be called dieqn, could be a shell script (see further) etc. Now you have a troff input stream, which can have some PostScript interspersed with it. To get a troff output file (at CMU called .dvi) you push the stuff through ditroff (or troff or whatever the local people call it). Note that the new version of troff is assumed, for dealing with older versions of troff see an earlier note on this subject. ditroff -Tdevice < file.eqn > file.dvi Note that the code generated by ezprint assumes that the device name is psc. If it isn't psc it will suppress the raw PostScript in the input. You will find in the input stream (file.eqn) things like .if '\\*(.T'psc' \{\ The Postscript stuff .\} So if your ditroff uses an other name to denote a postscript printer, you need to change the test accordingly. As an alternative, you can dive into the bowels of the system and link (symbolic) usr/lib/dev{whatever} to /usr/lib/dev/psc. Then you can still use psc as device name. There is another caveat, the ditroff you call might actually be a shell script which performs some ``intelligent'' stuff for you [An Andrew ToolKit view (fnotev) was included here, but could not be displayed.]. One of the things it might do, is always spool your output to some printer or take the -Tflag and change it into whatever the operation people choose to call the PostSCript printer. Other scripts try to figure out what preprocessors you need to run and are bound to do the wrong thing. A common flag which these scripts is -t, which generates troff out put (dvi) on the standard output with ezprint -t | eqn output. Anyway, try to get your hands on the real troff. Now, after you ran the real troff, now you have file.dvi, which actually contains troff output, which might be also have PostScript in it. Now you have to convert the troff output to PostScript, and now a new constraint pops up. It is assumed to be converted to PostScript by psdit, a program from Adobe, part of the TranScript package. If you don't have this (you have for instance devps), you are in a jam if you have PostScript (so rasters or zip in the original datastream) since the way the file.dvi contains the PostScript can only be understood by psdit. Anyway, to create your final PostScript, one does psdit < file.dvi > file.psc # whow, are we happy Of course, ezprint might do things slightly different (it actually let lpr run the psdit), but following the above scheme might tell you were things break. Looking into the various temporary files might also give you an idea where things break. As you can see, there is no magic involved, it's all done with smoke an mirrors. Enjoy, jaap PS. All this convoluted mess should actually be documented in the next release notes. I'm not sure whether this will actually happen.