suter@latcs1.oz.au (David Suter) (03/20/90)
I have tried to print dvi files produced by PCtex (on a PC) by kermit'ing the files on to a mainframe which has a laser printer attached. All I get is virtually blank pages with a few lines (straight lines - not text) every now and then. On checking the dvi files produced on the PC and on the mainframe I find that the PC files are generally longer. The previewer (dvi2scr) on the PC "correctly" displays dvi files produced either on the PC or on the mainframe. So - at least in some sense the contents of the files are "equivalent". My knowledge of dvi files is virtually nonexistent but I can imagine that two different latex programs can produce two different but essentially equivalent dvi files. But I am at a loss as to why the dvi files will not print the same. I suspect the answer has something to do with a deficiency in the printer driver causing it to fail to interpret properly the dvi file produced by the PCtex program. Can anyone enlighten me further on the possible causes and remedies. (p.s. the files are not being corrupted in transfer from one machine to the other) d.s.
dhosek@jarthur.Claremont.EDU (---) (03/21/90)
In article <7457@latcs1.oz.au> suter@latcs1.oz.au (David Suter) writes: >I have tried to print dvi files produced by PCtex (on a PC) by kermit'ing >the files on to a mainframe which has a laser printer attached. All I get >is virtually blank pages with a few lines (straight lines - not text) >every now and then. [stuff deleted] >I suspect >the answer has something to do with a deficiency in the printer driver >causing it to fail to interpret properly the dvi file produced by the PCtex >program. Can anyone enlighten me further on the possible causes and >remedies. >(p.s. the files are not being corrupted in transfer from one machine to the >other) >d.s. 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). Some important questions that need answers: * What system are you uploading to and with what Kermit options? * What driver is causing the problem on the upload system? -dh -- Important note: The Anti-Social Committee will not be meeting this week. UUCP: uunet!jarthur!dhosek Internet: dhosek@hmcvax.claremont.edu
ae219dp@prism.gatech.EDU (Devon Prichard) (03/21/90)
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. -- |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| | Devon Prichard making the world safe for helicopters ... | | ae219dp@prism.gatech.edu | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
jjsf@gmv.es (Julio Sanchez) (03/21/90)
In article <5224@jarthur.Claremont.EDU> dhosek@jarthur.Claremont.EDU (---) writes: >In article <7457@latcs1.oz.au> suter@latcs1.oz.au (David Suter) writes: >[stuff deleted] > >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. I would appreciate input from people who are doing this. The same goes for font files. Julio Sanchez Ph. +34 1 534 30 04 Grupo de Mecanica del Vuelo, S.A. (GMV) Fax +34 1 533 32 50 Cristobal Bordiu, 35 Telex 48487 GMEV E E-28003 MADRID jsanchez@gmv.es SPAIN mcsun!gmv.es!jsanchez@uunet.uu.net uunet!mcsun!gmv.es!jsanchez
dhosek@jarthur.Claremont.EDU (---) (03/22/90)
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
dhosek@jarthur.Claremont.EDU (---) (03/22/90)
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
tml@hemuli.tik.vtt.fi (Tor Lillqvist) (03/22/90)
In article <5259@jarthur.Claremont.EDU> dhosek@jarthur.Claremont.EDU (---) writes: >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. I used this method when I ported TeX to the HP1000 some six years ago. It has a really braindead file system, and this was a trick I considered necessary. Of course, the HP1000 port is very obsolete by now. (I must admit that the Pascal/1000 compiler did compile TeX without problems, you can't say the same of many Unix Pascal compilers.) -- Tor Lillqvist, working, but not speaking, for the Technical Research Centre of Finland