| Device-independent (DVI) | |
| Extension: | .dvi |
| Mime: | application/x-dvi (unofficial) |
| Nomimecode: | yes |
| Owner: | David R. Fuchs |
| Genre: | document |
The device independent file format (DVI) is the output file format of the TeX typesetting program, designed by David R. Fuchs and implemented by Donald E. Knuth in 1982.[1] Unlike the TeX markup files used to generate them, DVI files are not intended to be human-readable; they consist of binary data describing the visual layout of a document in a manner not reliant on any specific image format, display hardware or printer. DVI files are typically used as input to a second program (called a DVI driver) which translates DVI files to graphical data. For example, most TeX software packages include a program for previewing DVI files on a user's computer display; this program is a driver. Drivers are also used to convert from DVI to popular page description languages (e.g. PostScript, PDF) and for printing.
TeX markup may be at least partially reverse-engineered from DVI files, although this process is unlikely to produce high-level constructs identical to those present in the original markup, especially if the original markup used high-level TeX extensions (e.g. LaTeX).
DVI differs from PostScript and PDF in that it does not support any form of font embedding, instead merely referencing external font names. (Both PostScript and PDF formats can embed their fonts inside the documents.) For a DVI file to be printed or even properly previewed, the fonts it references must be already installed. Like PDF, DVI uses a limited sort of machine language with termination guarantees that is not a full, Turing-complete programming language like PostScript.
As of 2004 there is a compilation of the specifications a DVI driver must implement by the "TUG DVI Driver Standards Committee".[2] It seems to be based on a TUGboat article of the same name from 1992, but which is much shorter.[3] These documents do not specify the endianness, which is however big endian, as can be seen looking into a DVI file itself.
The DVI format was designed to be compact and easily machine-readable. Toward this end, a DVI file is a sequence of commands which form "a machine-like language", in Knuth's words.[1] Each command begins with an eight-bit opcode, followed by zero or more bytes of parameters. For example, an opcode from the group 0x00 through 0x7F (decimal 127), set_char_''i'', typesets a single character and moves the implicit cursor right by that character's width. In contrast, opcode 0xF7 (decimal 247), pre (the preamble, which must be the first opcode in the DVI file), takes at least fourteen bytes of parameters, plus an optional comment of up to 255 bytes.
In a broader sense, a DVI file consists of a preamble, one or more pages, and a postamble. Six state variables are maintained as a tuple of signed, 32-bit integers:
(h,v,w,x,y,z)
These variables can be pushed to or popped from the stack. In addition, the current font f is held as an integer value, but is not pushed and popped with the rest of the state variables when the opcodes push or pop are encountered. Font spacing information is loaded from TFM files. The fonts themselves are not embedded in the DVI file, only referenced by an integer value defined in the relevant fnt_def''i'' op. (This is done exactly twice for each loaded font: once before it is referenced, and once in the postamble.) f contains an integer value of up to four bytes in length, though in practice, TeX only ever outputs font numbers in the range 0 through 255.
Similarly, the DVI format supports character codes up to four bytes in length, even though only the 0–255 range is commonly seen, as the TFM format is limited to that range. Character codes in DVI files refer to the character encoding of the current font rather than that of the system processing it. This means, for instance, that an EBCDIC-based system can process a DVI file that was generated by an ASCII-based system, so long as it has the same fonts installed.
The DVI format does not have support for graphics except for the most basic black-and-white boxes. Instead DVI has a general escape/extension mechanism, known as specials (expressed by the \special command in TeX), which defers graphics (and color) to post-processing filters. There are numerous DVI specials, the most notable of which are PostScript specials, but other programs like tpic have their own.[4]
DVI files are often converted into PDF, PostScript, or PCL format for reading and printing. They can be also viewed directly by using DVI viewers.
The first DVI previewers capable of on-screen previewing and modification of LaTeX documents ran on Amigas.[10] [11]
dvipdf is a tool to translate DVI files (generated by TeX) to PDF files. In current Linux distributions like Ubuntu, it is a thin wrapper around dvips and Ghostscript, and copyrighted to Artifex Software (the makers of Ghostscript).[12] A possibly different program with the same name—described as a modified version of dvips—was announced in the late 1990s by Sergey Lesenko,[13] [14] [15] however it was apparently never released.[16] [17]
dvipdfm is a DVI-to-PDF translator developed by Mark A. Wicks. The early documentation of dvipdfm specifically mentions the limited availability of Lesenko's dvipdf as a reason for creating dvipdfm.[18] dvipdfm supports most of the newer special functions of the PDF format, including bookmarks, annotations, thumbnails, and dvips specials—a feature making possible the inclusion of Encapsulated PostScript (.eps) files like METAPOST output—as well inclusion of JPEG and PNG images; other features of dvipdfm include partial font embedding (reducing file size) and balancing the internal PDF document trees to speed up rendering of large documents.[4] Many of these features (except for the direct support for .eps files[19]) are also present in pdfTeX, which typesets TeX directly to PDF. The 2004, 4th edition of the Guide to LaTeX compares them in the following way:[20]
dvipdfmx is an extended version of the dvipdfm DVI-to-PDF translator, included in current TeX distributions like TeX Live 2014[21] and MiKTeX 2.9.[22] The primary goal of the dvipdfmx project is to support multi-byte character encodings and CJK character sets for East Asian languages.[23] dvipdfmx is also included (in a somewhat modified form) in XeTeX.[4]
The 2nd, 2008 edition of the LaTeX Graphics Companion makes the following workflow suggestion:[4]