maer@ethz.UUCP (Matthias Ernst) (12/19/89)
I tried to tranfer a dvi-file created on a IBM-PC to a VAX. Beim verarbeiten auf der VAX bekomme ich allerdings immer die Fehlermeldung Invalid DVI-File Format. I assumed that DVI-file formats are identical on different systems.?? Thanks for any help Tilo Levante ETH Zuerich Labor fuer physikalische Chemie 8092 Zuerich
halliday@cheddar.cc.ubc.ca (Laura Halliday) (12/20/89)
In article <2874@ethz.UUCP> tilo@nmr.lpc.ethz.ch writes: > >I tried to tranfer a dvi-file created on a IBM-PC to a VAX. >Beim verarbeiten auf der VAX bekomme ich allerdings immer >die Fehlermeldung Invalid DVI-File Format. > >I assumed that DVI-file formats are identical on different >systems.?? They are. A couple of questions would help us help you: 1. What operating system does the VAX run? VMS? Some flavour of Unix? Something else? 2. What file transfer program did you use? What settings? Parity, stop bits, etc.? >Thanks for any help You're welcome. ...laura
ken@cs.rochester.edu (Ken Yap) (12/20/89)
|I tried to tranfer a dvi-file created on a IBM-PC to a VAX. |Beim verarbeiten auf der VAX bekomme ich allerdings immer |die Fehlermeldung Invalid DVI-File Format. | |I assumed that DVI-file formats are identical on different |systems.?? Yes, but when you transfer a binary file between some systems the remainder of the last fixed size block is padded with nulls. DVI format requires at least 4 octal 337 bytes at the end. You need to pad the block with octal 337.
ms361@leah.Albany.Edu (Mark Steinberger) (12/20/89)
In article <2874@ethz.UUCP>, maer@ethz.UUCP (Matthias Ernst) writes: > > I tried to tranfer a dvi-file created on a IBM-PC to a VAX. > Beim verarbeiten auf der VAX bekomme ich allerdings immer > die Fehlermeldung Invalid DVI-File Format. > > I assumed that DVI-file formats are identical on different > systems.?? 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? --Mark
ron@woan.austin.ibm.com (Ronald S. Woan) (12/20/89)
In article <2874@ethz.UUCP>, maer@ethz.UUCP (Matthias Ernst) writes: > I assumed that DVI-file formats are identical on different > systems.?? They should be, except in environments (VM/CMS) where you have to shove the DVI file into a fixed file type. Did you make sure to transfer the file in binary mode? Ron +-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+ +------------------------------My Employer----------------------------------+ + Ronald S. Woan (IBM VNET)WOAN AT AUSTIN, (AUSTIN)ron@woan.austin.ibm.com + + outside of IBM @cs.utexas.edu:ibmchs!auschs!woan.austin.ibm.com!ron + + last resort woan@peyote.cactus.org +
chris@mimsy.umd.edu (Chris Torek) (12/20/89)
>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
bartho@obs.unige.ch (PAUL BARTHOLDI) (12/21/89)
In article <2874@ethz.UUCP>, maer@ethz.UUCP (Matthias Ernst) writes: > I tried to tranfer a dvi-file created on a IBM-PC to a VAX. > Beim verarbeiten auf der VAX bekomme ich allerdings immer > die Fehlermeldung Invalid DVI-File Format. > > I assumed that DVI-file formats are identical on different > systems.?? > I will assume that you did a binary transfer (ftp? kermit? ...). but that is not all. most dvi2xxx on the vax assume 'fixed' length record format, while ftp and kermit will transfer 'constant' length records but will not create 'fixed' length files. I think that CKermit (on the vax) can create 'fixed' files with the command 'set file type fixed' , but Kermit32 is so much faster that I almost never use it. Now you can 'convert' your file to a 'fixed' format : 1. analyze/rms/fld <your dvi file> this will produce a short new file with extension .fdl 2. edit/fdl <your fdl file> changing the format to 'fixed' and possibly length to '512' . (you can also do it without the /fdl but with the manual. it will be faster!) 3. convert/fdl=<your new fdl file> <your old dvi file> <your new dvi file> and that is all ! (and usualy, it WORKS ...) The only problem encountered was with a dvi file with 1023 bytes records. convert can extend/pad records but not cut them in smaler pieces. For this, we have a small fortran program that does the trick ... By the way, you may have the same problem porting fonts. use similar solutions! Frohe Weihnachten und glukliches neues Jahr Paul Bartholdi - Observatorium Genf
jbw@unix.cis.pitt.edu (Jingbai Wang) (12/23/89)
In article <2874@ethz.UUCP> tilo@nmr.lpc.ethz.ch writes: > >I tried to tranfer a dvi-file created on a IBM-PC to a VAX. >Beim verarbeiten auf der VAX bekomme ich allerdings immer >die Fehlermeldung Invalid DVI-File Format. > >I assumed that DVI-file formats are identical on different >systems.?? > >Thanks for any help > > >Tilo Levante >ETH Zuerich >Labor fuer physikalische Chemie >8092 Zuerich From the English parts I can understand, you can do the following: with kermit, on VAX/VMS kermit-32>set file type fixed kermit-32>server ... ms-kermit>send mydvi.dvi DVI file on VMS has fixed record length of 512bytes/record. If you use binary mode, the record length is screwed up. With ftp: ftp>binary ftp>put mydvi.dvi JB Wang