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.