🚀 go-pugleaf

>In article <2874@ethz.UUCP> maer@ethz.UUCP (Matthias Ernst) writes:
>>I assumed that DVI-file formats are identical on different
>>systems.?? 

(The answer is `yes and no'.)

In article <2336@leah.Albany.Edu> ms361@leah.Albany.Edu
(Mark Steinberger) writes:
>I've had the same problem transferring a dvi from a unix machine to
>a vax. The driver just wouldn't accept it. I suspect it has something
>to do with the fact that vaxes have more than one type of file.
>Are there any vax experts out there who'd care to comment?

First of all, `VAX' does not mean `VMS'.  If you mean `VMS', please say
`VMS'.  (`VAX' also does not mean `Unix or VMS'---remember DEC's
real-time O/S for the VAX?  And there is Mach, and SunOS too.)

There are two likely sources for the problem.  One is that a DVI file
is a `binary' file (not made entirely of printable characters) and such
files sometimes get munched by various host-to-host transfer
protocols.  E.g., Internet FTP requires using binary mode.

The other possibility is the VMS TeX implementation itself.  VMS is
saddled with `file formats' at the RMS level.  If you use the wrong
format, none of the system utilities can deal with your file.  (This
situation has improved since VMS version 2, which is the only one I
ever used.)  Some VMS TeX implementations therefore choose a fixed
512-byte record binary file format, with which RMS can deal
efficiently.  This, however, requires that DVI files be padded out to a
multiple of 512 bytes long.  TeX itself requires that a DVI file end
with at least four, and sometimes up to seven, `filler' bytes (code 223
decimal), such that the file size is a multiple of four bytes.  On
these VMS systems, instead of four to seven bytes, DVI files are padded
with up to 515 bytes.

At any rate, on these systems the file readers expect fixed 512-byte
records and expect the last one to be padded with 223 bytes to fill the
entire record.  If the imported DVI file is shorter, and is somehow
interpreted as 512-byte records, the last record will be too short.
Exactly what the reader will see, I cannot say, but it will not be
padded to 512 bytes with 223s.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris