⟦3975dd9a6⟧

TextFile

\chapter{Conversion of {\tt DVI} Files to \protect\PS{} Files}
% ============================================================

\section{Introduction}
% ====================
	In this chapter I will give a brief overview over the problems
associated with converting {\tt DVI} files to \PS{} files. The next
chapter will deal with the issue of using \PS{} fonts in \TeX.

	As \PS{} is a high level programming language, whereas {\tt DVI} files can be thought
of as programs written in assembler, it seems to be rather straight forward to
convert a {\tt DVI} file into a {\PS} file. Each {\tt DVI} file
instruction can interpreted by a small \PS{} procedure. But things turn
out to be not quite that easy.

\section{The Driver's Coordinate System}
% ======================================
\subsection{Basics}
% =================
	\TeX's coordinate system and the coordinate system of the driver
have been made identical in this driver as far as origin and orientation
of the axis are
concerned: the origin of both coordinate systems is in the upper left corner
1''~to the right and 1''~ down from the physical edge
of the paper. The positive horizontal direction is right, and the
positive vertical direction is down.

	The unit of coordinates generated by the driver is {\it pixels},
i.e., the resolution of the \PS{} printer to be used must be known (it
must be known at least for optimal quality output).
Therefore, \PS{} files generated by this driver
are strictly spoken not device independent. The can be printed
on any \PS{} printer with a different resolution with a loss of quality.
All positioning information sent to
the \PS{} printer is always in integer pixels.

	The \PS{} {\tt setmatrix} operator is used to set up the coordinate
system. The {\tt setmatrix} matrix used in {\tt dvitps} is {\tt [ a 0 0 -a b c ]} for
portrait mode. {\tt a} is the conversion factor from pixels to
\PS's points (also called big points in \TeX, abbreviated ``bp''). There
are 72~bp to an inch. {\tt b} and {\tt c} reflect the
shift of the origin of \TeX{} which is 1''~down and 1~in''
right from the upper left corner of the paper (\PS's default origin is in the
lower left corner of the output page).

	This transformation matrix is modified as when
Pages are printed in landscape mode using the
matrix {\tt [ 0 a a 0 b' c']} for {\tt setmatrix}. Landscape
mode is invoked by the {\tt -L}~option
of the driver; \see{s-dvitps-man}, for details.

\subsection{The Specifics of Setting Up the Coordinate System}
% ============================================================
	\PS{} definitions generated by this driver, which refer to setting up the
coordinate system and which are written to the \PS{} output of the driver, are the
following:
\begin{itemize}
	\item {\tt /DviTranslateVector-X}, {\tt /DviTranslateVector-Y}. This
		vector is applied first to the current coordinate system. If the
		current \PS{} coordinate system is the default (origin in the lower
		left corner, positive x-axis direction is to the right and
		positive y-direction is up), then the origin of the coordinate
		system, after this transformation was applied,  moved~1" to the
		right and 1"~from the top of the upper left corner of the paper.
	\item {\tt /DviOrientationMatrix}. This matrix is applied next.
		The matrix does not contain any translation component, i.e.~its $t_{x}$ and $t_{y}$ are both
		zero. The purpose of this matrix is to
		\begin{itemize}
			\item Scale the X and Y axis appropriately,
			\item Set the orientations of those axis properly.
		\end{itemize}
	\item The last operation affecting the CTM (current transformation matrix) of \PS{} is
		a translation by the values given through the vector {\tt Page-H-Offset} and {\tt
		Page-V-Offset} which reflects any shifting through the  {\tt -H} and
		{\tt -V}~options of the driver.
\end{itemize}

\section{{\tt Dvitype\/} and This Driver}
% =======================================
	The {\tt dvitps} driver follows the rules of {\it dvitype}. Only
integer positions are generated by the driver. All positioning
computations are done by the driver, not by the \PS{} interpreter inside
the printer. Relevant parts of {\tt dvitype} which are of central
importance to {\tt dvitps} are listed in \AppendixRef{c-dvitype-notes},
\page{}. The driver in particular has a ``maxdrift'' control
following {\it dvitype}. How a maxdrift control was implemented even in the
case of \PS{} fonts will be discussed in the next chapter.

\section{Testing the Positioning Mechanism}
% =========================================
	It is possible to test the driver's positioning computations rather
easily: after each change in position and/or after each {\tt show} operator
the printer position as computed by the driver is written to the \PS{}
file generated by the driver. This position is subsequently compared with
the actual position in the printer based on the {\tt currentpoint}
operator's information. A message is then printed into the
log file of the \PS{} printer, if the two positions differ by more than
a specified threshhold value.

	The resulting \PS{} files of the driver are very long.
This feature is no implemented in the current version of the driver but
was available previously.

\section{The Driver's \protect\PS{} Output}
% =========================================
\subsection{Introduction}
% =======================
	I will now discuss the structure of the \PS{} file generated by the
driver. This section also explains some of the decisions made to
made to generate \PS{} code of reasonable length.

	The driver will read in the preamble of a {\tt DVI} file immediately
followed by the postamble of the {\tt DVI} file. The main purpose of
reading in the postamble is to set up all fonts. At this
point the driver will exit with an error, if any of the font
related files can not be found. The driver will not attempt automatic
substitutions if, for instance, a necessary pixel file cannot be found.

	There are three types of \PS{} code, which are generated by the
driver. I will discuss these three types now:
\begin{enumerate}
	\item There are so called {\it prologue files}, which are standard
		pieces of \PS{} code containing \PS{} procedure
		definitions used by the \PS{} code generated by the driver.
	\item {\it Pass~0 output\/} of the driver contains bitmaps needed for
		the printing of characters of pixel file based fonts.
	\item {\it Pass~1 output\/} of the driver contains instructions to
		print text, to draw rules, to move the reference point and to
		print a page.
\end{enumerate}

\subsection{Pass 0}
% =================
Pass~0 of the driver has the following purposes:
\begin{enumerate}
	\item Download pixel patterns of characters of the pixel based fonts
		which were not downloaded so far (i.e., only patterns of
		characters not downloaded so far, will be downloaded).
	\item Establish any \PS{} fonts by downloading an encoding vector and
		a width vector. The purpose of the encoding vector and the width
		vector is discussed in the following chapter.
	\item Trigger the downloading of the necessary prologue files. There
		are various prologue files for various purposes, and only those
		prologue files which are actually needed, are downloaded. These
		decisions are made in pass~0.
		Which files are downloaded is explained in
		\SectionRef{s-i-dvitps}, \page{}.
	\item \PS{} code generated through \verb+\special+s. More details later.
\end{enumerate}

\subsection{Pass 1}
% =================
	Pass~1 of the driver is initiated pass~0 of a page was completed (the
driver processes one page after another, and for each page first Pass~0
is executed followed by Pass~1):
\begin{enumerate}
	\item Instructions to move to a specific location.
	\item Instructions to print text.
	\item Instructions to print rules.
	\item Instructions to print a page.
	\item \PS{} code included with the help of \verb+\special+s.
\end{enumerate}

\subsection{Sequence of Pass~0 and Pass~1 Output}
% ===============================================
	Adobe defines so called ``\PS{} conforming documents.'' The driver,
by default, does {\it not\/} generate conforming documents. The driver, in this
case, goes through the pages of a {\tt DVI} file executing  Pass~0
followed by Pass~1 for each page.

	In order to generate conforming document this can not be done. First
all pass~0s must be executed, followed by pass~1 for all pages.
Why this is the case will be explained shortly.

\section{Virtual Memory Management by the Driver}
% ===============================================
\label{s-vm-discussion}
	I will now discuss the issue of virtual memory in the context of
this driver.

\subsection{Some Basics}
% ======================
	To understand what follows is important in particular when you
include other \PS{} documents into a \TeX{} document.  The issue here is also of
interest where \PS{} code generated by this driver would be included into another \PS{}
document.

	Before I explain the handling of the virtual memory by {\tt dvitps},
let me make the following points:
\begin{enumerate}
	\item VM in \PS{} printers is a rare resource.
		The driver therefore includes an option to reset the VM of a
		printer.  In other words, any information downloaded up to this
		point in time (in particular prologue files and bitmaps of pixel based
		fonts) is lost due to the reset. The option of the driver to do
		this is~{\tt -z} followed by a number~$n$ specifying that the
		printer should be reset every $n$~pages.

			The resulting \PS{} file, when this option is used,
		 is effectively the concatenation of a set of \PS{}
		files, which would result from dividing the {\tt DVI} file in
		separate, $n$~page long {\tt DVI} files and the processing and
		printing these pages independently of each other.
	\item Bitmaps of characters should be downloaded only once. In other
		words, pass~0 output of a page~$i$ will be used by subsequent
		pages.
	\item Prologue files are included as part of pass~0 output. They
		therefore survive between pages.
\end{enumerate}

\subsection{Non Conforming Output, {\tt save} and {\tt restore} Structure}
% ========================================================================
	The {\tt save}~/~{\tt restore} structure of the \PS{} output generated by the driver
can be described as follows:
\begin{itemize}
	\item There is a {\tt save}~/~{\tt restore} pair at the very beginning
		and at the very end of the \PS{} output.
	\item The pass~1 output by the driver is enclosed into a {\tt save}~/~{\tt
		restore} pair, which is obviously nested inside the outermost {\tt save}/{\tt
		restore} pair just described.
	\item The pass~0 output is {\it not\/} included in a {\tt save} / {\tt
		restore} pair, because output of pass~0 is supposed to
		``survive.''
\end{itemize}

\subsection{Conforming Output}
% ============================
	The driver, when invoked with the {\tt -C}~option (conforming), will
first execute pass~0 on all pages to generate the necessary prologue information for
the output \PS{} file (conforming documents must have all
``page order independent'' \PS{} code in their prologue part, so that the pages
themselves can be rearranged if that is desired).

	The specification for conforming documents also specifies that the whole \PS{} code
should {\it not\/} be included inside a {\tt save} / {\tt restore} pair.
And this is what the driver does.

	Conforming documents which reset the VM of the printer are therefore
impossible. Therefore the {\tt -C} and the {\tt -z}~option of the
driver are incompatible and an error is generated in case both options
are used.

\subsection{Virtual Memory Problems}
% ==================================
	Let me now discuss what problems there are with the current VM
management by the driver, and what could be done about it:
\begin{enumerate}
	\item As already specified the driver has a {\tt -z} option. This option is followed by a
		number~$n$, which specifies the number of pages, after which a
		complete reset of the \PS{} interpreter takes place. This is
		actually achieved by enclosing each set of $n$~pages
		into one {\tt save}~/~{\tt restore} pair. This pair includes all
		prologue files and all downloaded bitmaps, so after the
		$n$th~page the \PS{} interpreter resumes execution with the
		previously settled VM.
	\item When ``ordinary'' documents are processed running out of VM
		occurs only very rarely. Problems are
		more likely to occur, when one of the first generation \PS{} laser printers is
		used. The reason for this is simple: their memory is simply very small.
	\item There are certain documents which cause headaches---even on the
		newer LaserWriter~IIs. Of course, you could buy an
		LaserWriter~II~NTX and extend its memory, but if you can't, then you have to use the
		{\tt -z}~option of the driver.

			This occurs in particular when an excessive number of fonts
		is used (font catalogues, see also the examples in
		\ChapterRef{c-examples} to \ChapterRef{c-examples3} in this
		document.)
	\item One reason it is rather difficult to estimate the precise
		amount of virtual memory occupied by the fonts in a \TeX{}
		document is that the \PS{} documentation does not provide for any
		way to estimate these values.
	\item The driver has an option~{\tt -w} to eliminate the width
		vector in \PS{} fonts. This amounts to significant savings in the
		amount of virtual memory used by \PS{} fonts. See
		\SectionRef{s-metrics}, \page{}, for details.
	\item There is of course the problem of estimating the amount of virtual
		memory required by \PS{} files included with psfig or in
		similar ways to print \PS{} figures and diagrams. Again, there is no real
		way to estimate the amount of needed virtual memory.
	\item One very sophisticated solution to handling the VM problem would be the
		following: the driver does not generate the \PS{} code offline,
		but feeds the \PS{} code directly to the \PS{} printer.
		Periodically it checks the amount of free VM using the \PS{}
		operator {\tt vmstatus}. If necessary the printer could be reset.
\end{enumerate}

\section{The Handling of Pixel Fonts by the Driver}
% =================================================
	There are three different pixel based font file formats which are all
handled by the driver: {\tt PXL}, {\tt GF} and {\tt PK}.
See \ChapterRef{c-install}, \page{}, for details. A bitmap of a character is loaded into
a standard array inside the driver. Then this bitmap is
copied into the \PS{} output file (pass~0). At this point, there is no longer any
distinction between the different pixel font file types.

	The widths of characters in general, but of pixel based characters in
particular, are always rounded to the nearest integer multiple of the resolution
of the \PS{} printer.

\section{Conforming Documents}
% ============================
	It was mentioned before that the \PS{} output of this driver does not
comply with the ``conforming document requirements'' as established by Adobe.
The reasons for that are:
\begin{enumerate}
	\item Historical. Older versions of the driver did not do it (that's
		a poor argument, I know).
	\item \PS{} output of \TeX{} is normally not included into other
		\PS{} files (this is not such a great argument either).
	\item VM management. I just discussed that generating conforming
		documents would not allow use of the~{\tt -z} option.
\end{enumerate}
	There is the {\tt -C} option, of course, which makes the drivers output
to conform to this standard.

	By default, the driver's \PS{} output does not comply with these conventions.

	The implication of making the driver comply with TranScript's
prerequesits are as follows:

	Making {\tt -C} the default
has the following disadvantages of this process:
\begin{itemize}
	\item There would be initially a huge delay because in the first
		sweep only bitmaps and other information is downloaded.
	\item The possibility of the driver to completely reset the \PS{}
		printer after a number of pages, as it is given through the {\tt
		-z}~option would make no sense.
\end{itemize}

	There is finally a different solution: one does indeed treat each
page separately downloading each character's bitmap on a page by page
basis. The disadvantage is that the resulting \PS{} file is three to four
times as large as it is using the current approach.

\section{Dimensions in the Driver Program}
% ========================================
	Let me briefly discuss the dimension units used in the
driver. The following comments refer to {\tt typedef}s as they are used
in the driver's source code.
\begin{enumerate}
	\item The type {\tt DVIU} ({\tt DVI} units) is used for
		dimensions from  {\tt DVI} files, in other words, {\tt DVIU}s
		usually contain dimensions in scaled points.
	\item Dimensions sent to the printer ({\tt PXLU}) are given in
		the unit pixels.  I commented before on the orientation of the
		coordinate system used by the driver.
	\item A lot of the dimension related items can be found in file {\tt
		dvitps/h/units.h}. In {\tt dvitps/src/main.c}
		you find the code, which computes the conversion factors {\tt HConv} and {\tt VConv}.
		Divide a value in {\tt DVIU} by one of these factors to get a
		value in {\tt PXLU}.
\end{enumerate}

\section{Rule Alignment}
% ======================

\subsection{Introduction}
% =======================
	This section discusses a problem I encountered with the alignment of
rules.  I first had a solution which worked but was kind of
unsatisfactory. Then Ken pointed me into the right direction: use \PS{}
operators {\tt transform} and {\tt itransform} to round the starting
point of any rule drawing operation. That fixed the problems.

\subsection{Testcases}
% ====================
	First of all I will now reprint a set of tables which I used to test
my fix. The tables are stored in a separate file {\tt testtables.tex} for
the convenience of testing rule alignment. Here are those testtables.

{
	\let\bye = \relax
	\input testtables.tex
}

\subsection{The Problem}
% ======================
	The problem with the above tables was that some of the vertical rules were not lineing up.
The reason for that seems to be a rounding error problem inside the \PS{}
interpreter of the laser printer I was using (a LaserWriter~II NT)
(Adobe will probably argue that my \PS{} code is not quite correct, and
that the fix outlined below is what I should apply).

\subsubsection{Fixing the Problem}
% ================================
	The fix of the problem is straight forward: here is the rules
prologue file (for an explanation see the \PS{} Language Reference
Manual, the ``red book,'' page~176.

	Here is the prologue file for printing rules defining {\tt /z}.
\ListVerb{rules.psr}

\subsection{Experimenting for Yourself}
% =====================================
If you try to experiment yourself with this problem proceed as follows:
\begin{enumerate}
	\item Run {\tt testtables.tex} through \TeX, generating {\tt
		testtables.dvi}.
	\item Run this files through the driver generating {\tt
		testtables.ps}.
	\item Now edit {\tt testtables.ps}. Search for the line
\btex
    transform round exch round exch itransform	% Replaced by rounded current point.
\etex
		in the definition of \PS{} procedure~{\tt /z}. Remove this line,
		and print the \PS{} file exhibiting problems with the alignment
		of rules.
\end{enumerate}
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦3975dd9a6⟧ TextFile

Derivation

TextFile
