aslam@uiucdcsp.cs.uiuc.edu (12/20/87)
Evidently, TeX dvi files generated on unix systems can not be printed
under VAX/VMS. I suspect there is some kind of record format conversion
required because VMS loves to decorate its files with all sorts of
record attributes. Does someone have a program that runs under VMS and
converts DVI files from unix-land to vms-island? I know I can always
transport the TeX source and generate the dvi file; there have been cases
where all I had was the dvi file.
Sohail Aslam
Department of Computer Science
University of Illinois
arpa aslam@a.cs.uiuc.edu
csnet aslam@uiuc.csnet
usenet {ihnp4,seismo}!uiucdcs!aslamkuo@skatter.UUCP (Dr. Peter Kuo) (12/29/87)
In article <77900003@uiucdcsp>, aslam@uiucdcsp.cs.uiuc.edu writes: > > > Evidently, TeX dvi files generated on unix systems can not be printed > under VAX/VMS. I suspect there is some kind of record format conversion > required because VMS loves to decorate its files with all sorts of > record attributes. Does someone have a program that runs under VMS and > converts DVI files from unix-land to vms-island? I know I can always > transport the TeX source and generate the dvi file; there have been cases > where all I had was the dvi file. > > Sohail Aslam > Department of Computer Science > University of Illinois > arpa aslam@a.cs.uiuc.edu > csnet aslam@uiuc.csnet > usenet {ihnp4,seismo}!uiucdcs!aslam You may not need any programs to fix your problem, except CONVERT on the VMS side. As I recall, VMS wants its DVI file in fixed-length records of 512 bytes. Since Unix doesn't care about that, that's probably why the two are not comptable. First you need to pad your Unix-DVI file to some multiple of 512 bytes; use hex FF as your padding (I think FF is the one to use; I forget now, need to look at my pad program again (8-) since I haven't used it for ages), then cook up a FDL file to convert your Unix-DVI file to 512-byte fixed-length records and it should work. I ran across a simialr problem with MicroTeX (from Addison-Wesley) v1.41A on my PC/XT and VMS. And the FDL did the trick; the new version of MicroTeX (v1.51A) puts out files in multiples of 512 bytes now. Drop me a line if you still have problems. I can look up my padding program. Peter/ p.s. Use VMS's DUMP to see what the last byte in the DVI file is, the device drivers look for that byte! And use that as your padding character. ------------------------------------------------------------------------------- Peter Kuo | Bitnet (VMS) : KUO@SASK Accelerator Laboratory | (a.k.a. The Beam Warehouse) | uucp (Unix) : !alberta\ Univ. of Saskatchewan | !ihnp4 -- !sask!skatter!kuo Saskatoon, Saskatchewan | !utcsri / CANADA S7N 0W0 | (Earth) | Ma Bell : (306) 966-8528 Disclaimer: I don't know what I am saying, I'm only a physicist. Don't quote me on anything! I speak only for myself. Opus: "Why, fer cryin' out loud..research physicists need Porsches, TOO!!" -- Bloom County
dao@cs.nott.ac.uk (David Osborne) (02/09/88)
Recently, someone described how to convert DVI files generated on a Unix system so they could be transferred to VAX/VMS and correctly interpreted. It involved padding the end of the file out to a 512-byte boundary with (I thought) the last character in the file. However, I tried that and one of Nelson Beebe's drivers which I run under VMS still said, "Are you sure this is a DVI file?" Could someone enlighten me, please? I remember seeing the article about it, but can't remember where (comp.text? TeXhax? UKTeX?...) It was in the last month or so, anyway. thanks in advance, Dave -- David Osborne +---------------------------------------------------------------------------+ | Cripps Computing Centre, University of Nottingham, Nottingham NG7 2RD, UK | | JANET: dao@uk.ac.nott.cs || cczdao@uk.ac.nott.vaxa | | UUCP: {...!mcvax}!ukc!nott-cs!dao | | ARPA: dao%cs.nott.ac.uk@ucl-cs.arpa || @ucl-cs.arpa:dao@cs.nott.cs.uk | | Phone: +44 602 506101 x2064 Voice: "Dave!" | +---------------------------------------------------------------------------+