🚀 go-pugleaf

In article <7294@hydra.gatech.EDU> ae219dp@prism.gatech.EDU (Devon Prichard) writes:
>From: dhosek@jarthur.Claremont.EDU (---)
>>The problem is almost definitely with the file transfer process. DVI is DVI is
>>DVI is DVI. An uncorrupted DVI file will be interpretable by any DVI driver
>>and produce more-or-less identical results (assuming of course that no funky things like \special's or device fonts 
>>are used).
>I'm not sure about this.  I LaTeX-ed a file on hydra.gatech.edu (a Sequent
>unix box) and FTP'd the file to a CYBER 855 running NOS 2.  I then
>tried to print the file to a Xerox laserprinter in Epic format (there
>is a utility to convert dvi to Epic).  The converter didn't understand
>the "version" of dvi the file was written in!!  the LaTeX on the
>Sequent is much more recent than that on the CYBER, as far as I know.

Unless your Cyber TeX is VERY old (around ten years old or so), this is not 
going to be a problem. The DVI format has been unchanged for a damned long
time. There is a variant version of TeX, TeX-XeT which produces a slightly
modified DVI file (DVI version 3) but it's not very widely used.

The first piece of data in the DVI file is the dvi_preamble command which
contains in it a version number. If your data transer process corrupts the
x'02 which is in the second byte or so, you've got a problem.

Another thing which can happen (I just remembered this now) is that on one
system (I forget which) DVI files and other TeX binaries have their length
encoded into them at the beginning (NAUGHTY NAUGHTY NAUGHTY), which can
cause problems. This may be on the Data General, but I forget.
-dh
-- 
Important note: The Anti-Social Committee will not be meeting this
                week.
                                   UUCP: uunet!jarthur!dhosek
                               Internet: dhosek@hmcvax.claremont.edu