Why does LaTeX not embed imported EPS images into the DVI file?

Experiment:

Compiling a file, having PSTricks code inside, in LaTeX (`latex.exe`), results in a self-contained DVI, where this PSTricks code is embedded.

But if the file has EPS images, the resulting DVI is no longer self-contained. If you delete the EPS images and open the DVI using a DVI viewer, the viewer will not show any images.

Question

Why does LaTeX (`latex.exe`) not embed imported EPS images into the DVI file?

-
@Andrew, @Karl: Thank you for good editing. –  xport Jun 15 '11 at 11:46

DVI is never self-contained: It doesn't contain fonts. Apart from this: The pstricks package puts the code in the dvi (through \special commands). What should it do else? It can't refer to external files. The graphics package doesn't include eps as it is not necessary. The driver (dvips) will have to get the fonts anyway. So it can also load the eps.

-
+1 it is accepted because it is more understandable. –  xport Jun 15 '11 at 11:43
Are there packages to embed eps images and fonts into the resulting DVI file? –  xport Jun 15 '11 at 12:34
What would you gain if the driver (dvips or dvipdfmx) is not able to handle such embeded code? If you want a selfcontained format use ps or pdf. –  Ulrike Fischer Jun 15 '11 at 12:41

`dvi` is a DeVice Independent format, the resaon why everything except the default text is referenced and not embedded. If someone has another directory structure the dvi will be useless. It makes only sense on the same machine.

-
+1 too but I prefer the Ulrike's answer that is more understandable. Thank you. –  xport Jun 15 '11 at 11:44

The DVI format is older than Postscript and cannot describe Postscript. It does have an extension mechanism, namely DVI special codes, but the DVI specification gives them no semantics and so they depend on special nonstandard extensions in the DVI renderer to be useful.

The dvips program did attach significance to certain DVI specials: it allowed Postscript code to be encoded using them, which are now known as Postscript specials. There are other DVI extensions, such as the Hypertex specials used by the hyperref package or the TPIC specials used by eepic. These extensions have been encoded using text, and initial characters used to identify the type of special have ensured that the DVI specials provided by different extensions have not conflicted. In a way, this has been good luck: DVI specials have nothing like a namespace mechanism to ensure conflicts don't occur.

Ulrike's answer mentions the pstricks package, which uses these Postscript specials, as do some other packages, such as the DVI renderer for beamer. But to DVI renderers that do not recognise the dvips encoding of Postscript, the use of DVI specials will be meaningless and typically will be ignored.

Since Postscript is not "native" to DVI, it makes sense not to embed it: for one thing, this is more memory efficient since the Postscript does not need to be escaped. The standard for this is to use the psfile DVI special introduced by dvips.

-
+1 for completing the Ulrike's answer and explaining the details. –  xport Jun 15 '11 at 12:43