% $Id: faq-dvi.tex,v 1.2 2014/01/28 18:17:36 rf10 Exp rf10 $

\section{\acro{DVI} Drivers and Previewers}

\Question[Q-dvips]{\acro{DVI} to \PS{} conversion programs}

The best public domain \acro{DVI} to \PS{} conversion program, which
runs under many operating systems, is Tom Rokicki's \ProgName{dvips}.
\ProgName{dvips} is written in \acro{C} and ports easily.  All current
development is in the context of Karl Berry's \ProgName{kpathsea}
library, and sources are available from the \texlive{} repository,
and versions are available in all \TeX{} distributions that recognise
the use of \PS{}.

An \acro{VMS} versions is available as part of the \acro{CTAN}
distribution of \TeX{} for \acro{VMS}.

A precompiled version to work with em\TeX{} is available on \acro{CTAN}.
\begin{ctanrefs}
\item[\nothtml{\rmfamily}\MSDOS{} and \latexhtml{\acro{OS/}}{OS/}2]%
 \CTANref{dvips-pc}
\item[\nothtml{\rmfamily}VMS distribution]\CTANref{OpenVMSTeX}
\end{ctanrefs}

\Question[Q-HPdrivers]{\acro{DVI} drivers for \acro{HP} LaserJet}

The em\TeX{} distribution (see \Qref[question]{\TeX{} systems}{Q-TeXsystems})
contains a driver for the LaserJet, \ProgName{dvihplj}.

Version 2.10 of the Beebe drivers supports the LaserJet. These drivers
will compile under Unix, \acro{VMS}, and on the Atari ST and
\acro{DEC}-20s.

For Unix systems, Karl Berry's \ProgName{dviljk} uses the same
path-searching library as \ProgName{web2c}.
\begin{ctanrefs}
\item[\nothtml{\rmfamily}Beebe drivers]\CTANref{beebe}
\item[dviljk]\CTANref{dviljk}
\end{ctanrefs}

\Question[Q-otherprinters]{Output to ``other'' printers}

In the early years of \TeX{}, there were masses of \acro{DVI} drivers
for any (then) imaginable kind of printer, but the steam seems rather
to have gone out of the market for production of drivers for
printer-specific formats.  There are several reasons for this, but the
primary one is that few formats offer the flexibility available
through \PS{}, and with
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}} (and its
huge range of printer drivers) there is now little demand for new
printer driver development.

Thus, it is reasonable to \Qref*{generate \PS{}}{Q-dvips}, and
use \href{http://www.ghostscript.com/}{\ProgName{ghostscript}} to send
the resulting \PS{} output to the printer you actually have.

(If you are using a Unix system of some sort, it's generally quite
easy to insert
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}} into the
print spooling process, which makes printing \emph{really} simple.)
\LastEdit{2013-05-29}

\Question[Q-previewers]{\acro{DVI} previewers}

Em\TeX{} for \acro{PC}s running \MSDOS{} or \acro{OS/}2, \miktex{} and
XEm\TeX{} for \acro{PC}s running Windows and Oz\TeX{} for the Macintosh, all
come with previewers that can be used on those platforms. Em\TeX{}'s
previewer can also be run under Windows~3.1.

Commercial \acro{PC} \TeX{} packages (see % ! line break
\Qref[question]{commercial vendors}{Q-commercial})
have good previewers for \acro{PC}s running Windows, or for Macintoshes.

For Unix systems, there is one `canonical' viewer, \ProgName{xdvi}.
\ProgName{Xdvik} is a version of \ProgName{xdvi} using the
\ProgName{web2c} libraries; it is now built from the same distribution
as \ProgName{xdvi}.  The \texlive{} distributions for Unix systems
include a version of \ProgName{xdvik}.

Alternatives to previewing include
\begin{itemize}
\item conversion to `similar' \acro{ASCII} text (see
 \Qref[question]{converting to \acro{ASCII}}{Q-toascii}) and using a
 conventional text viewer to look at that,
\item generating a \PS{} version of your document and viewing it
 with a
 \href{http://www.ghostscript.com/}{\ProgName{ghostscript}}-based
 previewer (see
 \Qref[question]{previewing \PS{} files}{Q-PSpreview}), and
\item generating  \acro{PDF} output, and viewing that with
 \ProgName{Acrobat} \ProgName{Reader} or one of the substitutes for that.
\end{itemize}
\begin{ctanrefs}
\item[xdvi]\CTANref{xdvi}
\end{ctanrefs}
\LastEdit{2013-04-11}

\Question[Q-dvi-bmp]{Generating bitmaps from \acro{DVI}}

In the last analysis, any \acro{DVI} driver or previewer is generating
bitmaps: bitmaps for placing tiny dots on paper via a laser- or
inkjet-printer, or bitmaps for filling some portion of your screen.
However, it's usually difficult to extract any of those bitmaps any
way other than by screen capture, and the resolution of \emph{that} is
commonly lamentable.

Why would one want separate bitmaps?  Most often, the requirement is for
something that can be included in \acro{HTML} generated from \AllTeX{}
source~--- not everything that you can write in \AllTeX{} can be
translated to \acro{HTML} (at least, portable \acro{HTML} that may be
viewed in `most' browsers), so the commonest avoiding action is to
generate a bitmap of the missing bit.  Examples are maths (a maths
extension to the `|*|\acro{ML}' family is available but not
universally supported by browsers), and `exotic' typescripts (ones
that you cannot guarantee your readers will have available).  Other
common examples are generation of
sample bitmaps, and generation for insertion into some other
application's display~--- to insert equations into Microsoft
PowerPoint, or to support the enhanced-\ProgName{emacs} setup called
\Qref*{\ProgName{preview}-\ProgName{latex}}{Q-WYGexpts}.

In the past, the commonest way of generating bitmaps was to generate a
\PS{} file of the \acro{DVI} and then use
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}} to
produce the required bitmap format (possibly by way of \acro{PNM}
format or something similar).  This is an undesirable procedure (it is
tedious, involving requires two or three steps that run slowly) but it
served for a long time.

\AllTeX{} users may now take advantage of two bitmap `drivers'.  The
longer-established, \ProgName{dvi2bitmap}, will generate \acro{XBM} and
\acro{XPM} formats, the long-deprecated \acro{GIF} format (which is
now obsolescent, but has finally been relieved of the patent
protection of the \acro{LZW} compression it uses), and also
the modern (\acro{ISO}-standardised) \acro{PNG} format.

\ProgName{Dvipng} started out as a PNG renderer; from version 1.2 it can also
render to the GIF format. It is designed for speed, in environments that
generate large numbers of \acro{PNG} files: the \File{README} mentions
\ProgName{preview}-\ProgName{latex}, \ProgName{LyX}, and a few
web-oriented environments. Note that \ProgName{dvipng} gives
high-quality output even though its internal operations are optimised
for speed.
\begin{ctanrefs}
\item[dvi2bitmap]\CTANref{dvi2bitmap}
\item[dvipng]\CTANref{dvipng}
\end{ctanrefs}
\LastEdit{2013-04-19}

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.