Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!dhosek
From: dhosek@jarthur.Claremont.EDU (---)
Newsgroups: comp.text.tex
Subject: Re: dvi files and printer drivers
Message-ID: <5260@jarthur.Claremont.EDU>
Date: 21 Mar 90 18:48:01 GMT
References: <7457@latcs1.oz.au> <5224@jarthur.Claremont.EDU> <1626@colon.gmv.es>
Organization: Pitzer College, Claremont, CA 91711
Lines: 26

In article <1626@colon.gmv.es> jjsf@colon.UUCP (Julio Sanchez) writes:
>I said:
>>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).
>Well DVI is DVI, more or less. On VAX/VMS, for instance, DVI files
>are organised in fixed-size records (512 bytes, I think) for
>the sake of efficiency. So transferring DVI files from a PC to a
>VMS system may be non-trivial.

This is why I wanted to know the systems involved in the process. MS-DOS and 
Unix are rare exceptions to the general rule of file systems mucking about 
with data. On VMS, the trick to effective data conversions is to use EDIT/FDL
to adjust the definitions (assuming that the data was at least transferred
into 512-byte records). VMS programs which read TeX binaries assume that the
data may have trailing 0s on the final record.

The best solution is to just not transfer binaries.

-dh
-- 
Important note: The Anti-Social Committee will not be meeting this
                week.
                                   UUCP: uunet!jarthur!dhosek
                               Internet: dhosek@hmcvax.claremont.edu