DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: T i

⟦86979dc9f⟧ TextFile

    Length: 31788 (0x7c2c)
    Types: TextFile
    Names: »install.tex«

Derivation

└─⟦52210d11f⟧ Bits:30007239 EUUGD2: TeX 3 1992-12
    └─⟦af5ba6c8e⟧ »unix3.0/DVIWARE.tar.Z« 
        └─⟦ca79c7339⟧ 
            └─⟦this⟧ »DVIware/laser-setters/dvi-to-ps/TeXPS/doc/install.tex« 

TextFile

\chapter{Overview of Sources, Installation}
% ========================================
\label{c-install}

	I will now describe the sources provided with this software plus all
the required installation procedures.

	The installation of the programs should be rather straight
forward. The driver itself is more or less independent of the programs
associated with the conversion of {\tt AFM} files into {\tt TFM} files
etc. I still recommend that at least initially you get all the software
installed, judge then, what you want to use and what not, and then remove
those parts, which you don't need.

	Remember to process and print this whole document on your computer
under all circumstances, even if you already have a printed copy of this
documentation.  This documentation is the test case for all the software. Once
you can produce this document on your machine you can be fairly confident that all your
software is running properly.

\section{Overview of the Provided Software}
% =========================================
\SectionRef{s-availability}, \page, explained already what software
you are provided with.  My main emphasis in the following will be to discuss
the {\tt TeXPS} directory and software itself in more detail.

\section{Source Directories}
% ==========================
	The following directories describe the \TeXPS{} software.  The
directories will be listed in logical order.
\begin{enumerate}
	\item {\tt lib}. A C-code library used by all of the
		programs. See \SectionRef{s-i-lib}, \page, for details.
	\item {\tt sup}. A support program for {\tt lex} and {\tt yacc} is contained
		in this directory; \see{s-i-sup}, for details.
	\item {\tt setup-lib}. All standard files for the setup processing are
		contained in this directory.
	\item {\tt setup}. The customization of \TeXPS{} is done from this directory;
		\see{s-setup}, for details.
	\item {\tt dvitps}.  All driver related code including {\tt .h} files and \PS{} code
		downloaded with the output generated by the driver.
		\See{s-i-dvitps}, for details.
	\item {\tt pfd2tfm}. The source for {\tt pfd2tfm}, the {\tt PFD} and {\tt AFM} to {\tt TFM}
		and {\tt PDR} conversion program. \See{s-i-pfd2tfm}, for details.
	\item {\tt printpdr}. This directory contains the source for
		{\tt printpdr}, a program to print a {\tt PDR} file as an ASCII
		text file. This is used to include the content of a {\tt PDR}
		file into the documentation.
	\item {\tt pfd}. Makefiles to generate the standard set
		of {\tt TFM} and {\tt PDR} files for the \PS{} fonts.
	\item {\tt h}. Include files which are used by many of the programs.
	\item {\tt man}. Manual pages.
	\item {\tt doc}. Documentation source directory containing the source
		code for this document, various macro files and other information.
	\item {\tt psfig}. The psfig macro package related files;
		\see{c-psfig}, for a description.
\end{enumerate}

\section{The Installation Procedure of the Software}
% ==================================================
\label{s-setup}
\label{s-makefiles}
	To simplify the installation all installation dependent variables are
collected in one place, a file called {\tt setup/local-defs}. This file is
used to generate makefiles in the various directories.  It is
essential that you understand the installation procedure, because it
facilitates a rapid installation of the software.

	You must {\it not\/} edit {\tt setup/local-defs}. Instead you should
generate a subdirectory which you call according to the name of your host
(that is you should generate a {\tt mkdir `hostname`}). Into this directory
you should copy {\tt local-defs} and {\tt makefile} from directory {\tt generic.host.name}
and then modify those two files (the {\tt local-defs} in {\tt `hostname`}
is later copied into the {\tt setup} directory).

	Here is how the installation works: each directory and each
subdirectory of any of the source directories contain a makefile called
{\tt IMakefile}. The file {\tt setup/local-defs} is
concatenated with {\tt IMakefile} to get {\tt Makefile} in each
directory. Actually it is not a real concatenation: comments and empty
lines in {\tt setup/local-defs} are not copied to each of the {\tt
Makefile}s. Also, as will be explained shortly, only one set of the
installation parameters from {\tt setup/local-defs} are actually copied.


	There is one important exception to this rule of generating {\tt
Makefile} from {\tt setup/local-defs} and {\tt IMakefile} and that is that
in the top level directory as well as the {\tt setup} directory only have
a {\tt makefile}, and no {\tt IMakefile} or {\tt Makefile}.

	{\bf In general you should be only required to modify {\tt
setup/`hostname`/local-defs}, and that should do it! If you need to do any
other modifications you don't seem to understand how the installation works.}

	The process of building {\tt Makefile}s from {\tt IMakefile}s and {\tt
setup/`hostname`/local-defs} is started by {\tt make prepare} in the top level
directory. Observe that this procedure removes certain object files and
binaries to force their recompilation. This was done to ensure that
(hopefully) all changes in settings in {\tt setup/`hostname`/local-defs} are passed
through to all binaries.

	You should do a {\tt make prepare} after each change to {\tt
setup/`hostname`/local-defs}. Then, in order to recompile and reinstall the
binaries, do a {\tt make all} or {\tt make relink} followed by {\tt make install} (the latter
probably as superuser).

	The software is designed in such a way that you can print and process
the documentation {\it without\/} installing it. That allows you to
generate this document first and to verify the workings of \TeXPS,
before you install it.

\subsection{Goals in the Top Level {\tt makefile}}
% ================================================
The following goals in the top level makefile should be of interest to
you:
\begin{enumerate}
	\item {\tt prepare}. You should execute a {\tt make prepare} each
		time you change {\tt setup/`hostname`/local-defs} (see below).
	\item {\tt prepare-2}. Use this for a secondary installation; \see{s-secondary-install},
		for details.
	\item {\tt relink}. A {\tt make relink} relinks all the binaries and
		is a good idea after a {\tt make prepare}.
	\item {\tt all}. Self explanatory. This is the way you should start
		out.  Note that the documentation is {\it not\/} processed.
	\item {\tt World}. {\tt make World} prepares everything and then compiles
		it. You should do a {\tt make clean} first.
	\item {\tt install}. Self explanatory. You should be superuser,
		probably.
	\item {\tt clean}. That removes all unnecessary files. You should
		execute this after you have installed all software. This also removes
		all {\tt Makefile}s, which means that you need to run a {\tt make
		prepare} next before you can do anything. Note: it does a {\tt make
		prepare} first.
	\item {\tt quick-clean}. Cleans it all up, but there is no {\tt make
		prepare} or removal of all {\tt Makefile}s.
	\item {\tt depend}. Recomputes the dependencies. Unless you changed
		the software there should be no need to do so.
	\item {\tt lint}. You know what that means, right?
	\item {\tt doc-dvi}. Generate the documentation's {\tt dvi} files.
	\item {\tt doc-dvi-2}. Remove all {\tt dvi} files and then regenerate
		them. Do this twice.
	\item {\tt print}. Print the source code, in the case of the
		documentation print the documentation, not the source code of it.
\end{enumerate}

\subsection{{\tt setup/`hostname`/local-defs}, {\tt setup/makefile}, etc.}
% ========================================================================
\label{s-local-defs}
	One essential ingredient of the installation procedure sketched before is that
{\tt setup/`hostname`/local-defs} can contain installation dependent variables of more
than one installation. Each installation is identified by a number which
precedes any definition in {\tt setup/`hostname'/local-defs}. This number is enclosed in
square brackets.

	To select the proper installation number you must edit {\tt
setup/`hostname`/makefile}.

	Let me now reprint the generic {\tt local-defs} file from {\tt setup/generic.host.name}.  Read the file
carefully because for your own installation all you have to do is to
change this file.  Please read the comment at the beginning of this file
pointing out to you how you should add your own installation dependent
settings.

\ListVerb{local-defs.tex}

\subsection{Secondary Installation}
% =================================
\label{s-secondary-install}
	By the way, two installations on the same machine are supported. The
way to proceed is as follows:
\begin{enumerate}
	\item Do your primary installation as outlined above and below.
	\item Prepare a directory {\tt `hostname`-2} in which you set up your
		secondary installation.
	\item Now execute the following commands:
		\begin{enumerate}
			\item {\tt make prepare-2}
			\item {\tt make all}
			\item {\tt make install}
		\end{enumerate}
		This will do the second installation on the same machine.
\end{enumerate}

\subsection{Your Local {\tt local-defs} File}
% ===========================================
The following file is the {\tt local-defs} file which you use locally. It
is a copy of the file {\tt setup/local-defs} which is extracted from {\tt setup/`hostname`}.
\ListVerb{local-local-defs.tex}

\subsection{The Necessary {\tt awk} Script Files}
% ===============================================
	From this file {\tt local-defs} with the help of {\tt awk} another file
{\tt local-defs.xx} is derived.  Let me reprint this {\tt awk}
file:
\ListVerb{../setup-lib/setup-ld.awk}

	Let me now reprint the {\tt makefile} of directory {\tt setup}, which
is responsible for setting up everything.
\ListVerb{makefile.setup}

\subsection{More Files}
% =====================
There are two more {\tt awk} files being used for the installation:
\ListVerb{../setup-lib/setup-1.awk}
\ListVerb{../setup-lib/setup-2.awk}

	Also the following file's text is appended to each makefile generated:
\ListVerb{../setup-lib/closing.defs}

\subsection{Top level {\tt makefile}}
% ===================================
And here is the source code of the top level makefile.
\ListVerb{makefile.top}

\section{Directory {\tt sup}: Support Programs}
% =============================================
\label{s-i-sup}
	This directory contains {\tt tokprep}, a token definition processing
program.

\section{{\tt lib}: ICS C-Program Library}
% ========================================
\label{s-i-lib}
	This directory contains a library of C-code procedures used by most of the
programs. There are a number of procedures defined in source files of
this directory which replace similar standard C~input/output procedures.
For instance, {\tt FExOpen} replaces {\tt fopen}, {\tt FExClose} replaces {\tt
fclose} and so forth. Most of these procedures integrate error processing
which in the case of {\tt fopen} and {\tt fclose} has to be done in the
calling program and some additional features as, for instance, the
automatic writing of standard input to a temporary file and such.

	The routines in this library are used in many other programs I have
written and therefore there are routines in there which you are not used
in \TeXPS.

\subsection{Input and Output to Files}
% ====================================
	Let me discuss the handling of files a little further. There are three file access
behaviors, which can be identified for ordinary programs (this section
was written when I developed the routines of {\tt foc.c}; I decided to
keep this section for future references).
\begin{enumerate}
	\item Files which are ``read only.'' The following subcases can be
		identified:
		\begin{enumerate}
			\item Standard files, like {\tt AFM} files. Normally a path
				is traversed to locate these files.
			\item Source files, like {\tt PFD} files, which are the
				main source of input to a program.
			\item Input from {\tt stdin} occurs. The following
				subcases can be identified:
				\begin{enumerate}
					\item While it seems that the input occurs from {\tt
						stdin} it is really a file the input occurs from.
						This is the case if a program {\tt xx} is invoked
						as follows: {\tt xx - < ll.tmp}, instead of {\tt
						xx ll.tmp}.  If this is true, the file can be
						used for input.
					\item The input occurs directly from {\tt stdin}, but
						{\tt stdin} is {\it not\/} really a file,
						for instance, because the input is read from a
						pipe.  There are two ways to handle this case:
						\begin{enumerate}
							\item Read directly from {\tt stdin}.
							\item Copy {\tt stdin} first to a
								temporary file, and then read from this
								temporary file.  This way of handling
								input from {\tt stdin} is necessary if
								input does not occur sequentially.
						\end{enumerate}
					\item If {\tt stdin} is written to a temporary file,
						then when {\tt stdin} is closed, this temporary
						file is removed. There is one special case
						(occurring in the driver), where this temporary
						file is not removed, because {\tt stdin} has to
						be read in a second time. The second time {\tt
						stdin} is closed this temporary file is also
						removed.
				\end{enumerate}
		\end{enumerate}
	\item Files, which are ``write only.'' These are the output files of
		a program. The following subcases can be identified:
		\begin{enumerate}
			\item It is a simple output file.
			\item Output occurs to {\tt stdout}. There are two subcases:
				\begin{enumerate}
					\item Output occurs to {\tt stdout} directly.
					\item Output occurs to a temporary file which later,
						when closed, is written to {\tt stdout}, and then
						the temporary file is subsequently removed.
				\end{enumerate}
			\item Shadow file output:
				\begin{enumerate}
					\item If the output file does not exist, output
						occurs to the specified file.
					\item If the output file exists, output occurs to a
						temporary file. When the output to the file is terminated, the
						two files (the original and the temporary file)
						are compared. If the two files differ, the
						output to the temporary file replaces the old
						output. If the files are identical the temporary
						file is removed (i.e., the original input file
						does {\it not\/} change, and also reflects no
						change in its ``last modification'' date).
				\end{enumerate}
		\end{enumerate}
	\item Temporary files. The main characteristics of those files is
		that the user is not really interested in their
		names. The user simply wants to use these files for input and
		output, and at the very end those files should simply go away.
		When I discuss temporary files now, then the cases of temporary
		files used for temporarily storing {\tt stdin} and {\tt stdout}
		are not included below.  These files go through the following stages:
		\begin{enumerate}
			\item The file name of the temporary file is generated.
			\item The file is opened for output.
			\item Information is written to the temporary file.
			\item The file is closed.
			\item From now on there are two different ways to proceed:
				\begin{enumerate}
					\item First possibility:
						\begin{enumerate}
							\item Temporary file is opened for input.
							\item Reading from file occurs.
							\item File is closed and removed.
						\end{enumerate}
					\item Second possibility:
						\begin{enumerate}
							\item Fork off other program which will read
								in the temporary file (the file is not opened by
								the main program).
							\item File is removed after forked off program
								has completed.
						\end{enumerate}
				\end{enumerate}
		\end{enumerate}
\end{enumerate}

\subsection{{\tt libics.a}, Source Files of this Library}
% =======================================================
The following source files belong to this library:
\begin{enumerate}
	\item {\tt dirs.c}. Directory manipulation programs.
	\item {\tt errors.c}. Error handling.
	\item {\tt exf.c}. Extended file manipulation procedures.
	\item {\tt files.c}. General file manipulation procedures.
	\item {\tt files2.c}. More of the same.
	\item {\tt getopt.c}. Program to read the options of a command line
		of a C-program.
	\item {\tt hash.c}. Hash table procedures.
	\item {\tt malloc.c}. Memory allocation procedures.
	\item {\tt nybbles.c}. Reading in nybbles (needed for the reading
			of {\tt PK} files).
	\item {\tt rcssup.c}. RCS support programs.
	\item {\tt readtfm.c}. Read in a {\tt TFM} file.
	\item {\tt str.c}. String handling procedures.
	\item {\tt texdim.c}. Some \TeX{} dimension related computations.
\end{enumerate}

\section{Common {\tt h} Directory}
% ================================
	The following additional code is common to all sources contained in
the directory~{\tt h} on the main level:
\begin{enumerate}
	\item {\tt char.h}. Character, kerning, ligature data structures.
	\item {\tt defs.h}. Standard definitions.
	\item {\tt extfil.h}. Extended file definitions. Needed to use the
		functions of {\tt lib/exf.c}.
	\item {\tt fontd.h}. Font definition data structures.
	\item {\tt pdr.h}. Data type for storing information from a {\tt PDR}
		file.
	\item {\tt tfm.h}. Definitions for {\tt TFM} files.
	\item {\tt units.h}. Definitions for dimension and dimension conversion
		procedures.
\end{enumerate}

\section{{\tt otherc}}
% =====================
This directory of ``other C code'' contains the following two files: 
\begin{enumerate}
	\item {\tt sig.c}. Signal handling, the same signal handling is used
		by all programs.
	\item {\tt defaults.c}. All defaults ``imported'' through {\tt
		local-defs} are contained in this file.
\end{enumerate}

\section{Directory {\tt dvitps}: The Driver Software}
% ===================================================
\label{s-i-dvitps}

	I will now discuss the directories of the driver sources.

\subsection{Directory {\tt dvitps/h}}
% ===================================
The directory {\tt dvitps/h} contains the following files:
\begin{enumerate}
	\item {\tt dvitps.h}. Standard definitions which apply to the driver.
	\item {\tt dvi-com.h}. Symbolic codes for the reading of {\tt DVI} files.
	\item {\tt emit.h}. Macros to write \PS{} code to standard output.
	\item {\tt gf-com.h}. Symbolic codes for reading {\tt GF} files.
	\item {\tt pk-com.h}. Symbolic codes for reading {\tt PK} files.
\end{enumerate}

\subsection{Directory {\tt dvitps/src}}
% =====================================
	The {\tt dvitps/src} directory contains the C source code of the
driver. 

	There are various debug switches in the sources. One is simply
called \verb+DEBUG+, which is used in almost all the sources. And then there
are also specialized debug switches like for instance \verb+DEBUG_GF+ to
turn on some debugging output for {\tt GF} files.  You will hopefully
never need any of those.
In general the \verb+DEBUG+ switch is not specifically
mentioned at the beginning of each source file,
but the other ``specialized'' debug switches are explained at the
beginning of each source file.

	Here is a list of the source files contained in this directory:
\begin{enumerate}
	\item {\tt capab.c}. Handles the reading in of a capability
		file. This capability file is currently only used to
		establish which font types the driver should know about
		and in which order it should look for.
	\item {\tt conv.c}. Dimension conversion routines.
	\item {\tt decodeargs.c}. Contains code reading in the arguments
		of the driver and code to print the usage message of the driver.
	\item {\tt dvi.c}. Contains code to read in the pre- and postamble of
		{\tt dvi} files. Also analyzes the font definitions
		in the postamble.
	\item {\tt dviloop.c}. This source file contains the code which is in
		charge of reading in all {\tt DVI} files and in charge of
		invoking all necessary functions to convert those {\tt DVI} files
		into a \PS{} file.
	\item {\tt emitc.c}. Emit character. Read in bitmaps from all type of files.
		See also {\tt shipc.c}.
	\item {\tt fonts.c}. Routines to read in fonts and related font file types.
	\item {\tt gf.c}. Read in {\tt GF} files, excluding bitmaps though.
	\item {\tt main.c}. Guess what.
	\item {\tt pass0.c}. Pass~0 related code, the pass, which generates
		all prologue files to download and all character bitmaps (for
		pixel file based fonts) and encoding and width vectors (for all
		\PS{} based fonts). Some of the \verb+\special+ commands are also handled
		here.
	\item {\tt pass1.c}. In  pass~1 of the driver the real text and
		movement \PS{} code is generated.
	\item {\tt pdr.c}. Reading in {\tt PDR} files. \PS{} fonts
		are completed set up, before any text is generated.
	\item {\tt pk.c}. Reading in {\tt PK} files, excluding bitmaps.
	\item {\tt pos.c}. Positioning business, including maxdrift control.
	\item {\tt ps.c}. \PS{} standard procedures to, for instance,
		generate the CTM (current transformation matrix).
	\item {\tt pxl.c}. {\tt PXL} files are read in by the procedures in
		this source file.
	\item {\tt search.c}.  Stuff which goes with {\tt dvi.c} to
		find the various pixel files.
	\item {\tt search2.c}. More of the same. This source file should be
		the only one to change in case you have your font files organized
		in a non-standard way, for instance, if you have stored your font
		files grouped by numerical file extensions.
	\item {\tt send.c}. Code to send \PS{} code to the output \PS{} file.
	\item {\tt send2.c}. More of the same.
	\item {\tt shipc.c}. Ship a character bitmap to the output \PS{} file.
	\item {\tt special.c}, {\tt special-tokens}, {\tt
		special-1.lex} and {\tt special-2.lex}. All files
		have to do with the handling of \verb+\special+;
		see \ChapterRef{c-special}, \page, for details.
	\item {\tt switchps.c}. Some rather special stuff allowing to
		direct the output of prologue files, pass~0 and pass~1
		output to various files.
	\item {\tt tpic\_support.c}. Code used by {\tt special.c}
		to support {\tt tpic}, \see{s-tpic}.
\end{enumerate}

\subsection{Directory {\tt dvitps/psr}}
% =====================================
	This directory contains \PS{} prologue file sources. From the files
in this directory compacted versions of these files are generated
which are included into the \PS{} file generated by the driver.
These programs have to be installed in such a way, that
the driver can combine them with the other \PS{} code.

	There is a {\tt DEBUG} switch in the {\tt
IMakefile}, which for a production installation should be removed.
There is a little C-program which takes care of the installation.
\begin{enumerate}
	\item {\tt ellipse.psr}. {\tt tpic} related \PS{} code.
	\item {\tt gray.psr}. Gray shading \PS{} code for verbatim listings.
	\item {\tt pixel-fonts.psr}. General \PS{} code needed for pixel file based fonts.
	\item {\tt pos.psr}. Positioning and printing commands
		with names one character long.
	\item {\tt ps-fonts.psr}. General code needed, when \PS{} fonts are used.
	\item {\tt reencode.psr}. Code to set the encoding vector in \PS{} fonts.
	\item {\tt set-widths.psr}. To define the width vector of \PS{} fonts.
	\item {\tt spline.psr}. Spline related prologue file for {\tt tpic}.
	\item {\tt texpre.psr}. Standard \PS{} code for each \TeX{} job.
\end{enumerate}

	From these files files with the file extension {\tt .pro} are
generated (essentially all comments and redundant white space is
removed), and these reduce files are used by the driver.

\subsection{Directory {\tt dvitps/pro}}
% =====================================
	This is a directory containing the {\tt .pro} files, which were
discussed in the previous section. This is a directory of intermediate
files.

\subsection{Directory {\tt dvitps/capab}}
% =======================================
	The file {\tt dvitpscap} contains the source code which controls which type of
font files and in which order will be searched for by the driver. This file is built from
the settings in {\tt setup-lib/local-defs}.

\section{Directory {\tt pfd2tfm}}
% ===============================
\label{s-i-pfd2tfm}
	This directory {\tt pfd2tfm} is the program which takes a {\tt PFD} file and generates
{\tt TFM} and {\tt PDR} files from it.

\subsection{Directory {\tt pfd2tfm/evs}}
% ======================================
	This directory contains the default encoding vectors which are used
by {\tt pfd2tfm}. The files contained in this directory are as follows:
\begin{enumerate}
	\item {\tt DefClasses}. By default {\tt pfd2tfm} will choose
		encoding and ligature files numbered~0. In this file you
		can specify different defaults.
	\item {\tt EncDef-0.ev}, {\tt EncDef-1.ev}, {\tt EncDef-2.ev}
		and {\tt EncDef-3.ev}. Each file contains one default encoding vector.
	\item {\tt LigDef-0.lig}. This file contains the only ligature default
		file which is currently used.
\end{enumerate}

\subsection{Directory {\tt pfd2tfm/h}}
% ====================================
This directory contains a number of files included by the sources of {\tt
pfd2tfm}.
\begin{enumerate}
	\item {\tt defenc.h}. Some definitions for the handling of
		the default encoding vectors and ligatures.
	\item {\tt pfd2tfm.h}. Standard definitions for this program.
	\item {\tt yaccreturn.h}. Definition for return values of {\tt yacc}.
\end{enumerate}

\subsection{Directory {\tt pfd2tfm/src}}
% ======================================
This directory contains the source files of {\tt pfd2tfm}.
It is a good idea to look into {\tt main.c}, because this should give a
pretty good idea of the major steps executed by this program. {\tt
pfd2tfm} forks off {\tt pltotf}, because
{\tt pfd2tfm} generates a property list, which is converted into a {\tt
TFM} file with the help of {\tt pltotf}. 

\begin{enumerate}
	\item {\tt afm.c}. {\tt AFM} file handling, also
		mapping by the encoding vector.
	\item {\tt defccv.c}. Default encoding vector business.
	\item {\tt defenc.lex}. Default encoding {\tt lex} part.
	\item {\tt emul.c}. Font emulation business.
	\item {\tt exc.c}. Exclusion of character code business.
	\item {\tt execps.c}. Execute \PS{} code business.
	\item {\tt fixw.c}. Anything which has to do with
		changing the widths of characters.
	\item {\tt kernlig.c}. Kerning and ligature handling
		of \TeX.
	\item {\tt ly.c}. {\tt lex} and {\tt yacc} business,
		see below. {\tt lex} uses routines from this
		file to read its input, and {\tt yacc} calls routines
		from this file, which in turn call {\tt lex}.
	\item {\tt main.c}. Guess what. Look at this file to
		get an idea about the structure of the whole program.
		You also can see there what {\tt pfd2tfm} does in
		case one chooses to emulate a font.
	\item {\tt mapfn.c}. Mapping stuff for short and long file
		names. This is relevant for systems where file names are
		restricted in how many characters they can have.
	\item {\tt pl.c}. Write property list in this file.
		The result is fed to {\tt pltotf}, which in turn
		generates a {\tt TFM} file.
	\item {\tt readtfm.c}. Read in a {\tt TFM} file, needed
		to get the width information to copy it into
		the {\tt PDR} file.
	\item {\tt remap.c}. Some code for the remapping of
		characters to different character codes than their
		default specified.
	\item {\tt texdefs.c}. Routines to write a bunch of
		\TeX{} \verb+\char+ definitions as macros to
		a {\tt .tex} file, which can be used later
		to access the characters of a font in a symbolic
		way.
	\item {\tt util.c}. Some utility routines.
	\item {\tt writepdr}. Routines to write {\tt PDR} files.
\end{enumerate}

There are some {\tt lex} and {\tt yacc} sources to read in {\tt PFD} files:
\begin{enumerate}
	\item {\tt pfd-1.lex}. First part of the lexical analyzer.
	\item {\tt pfd-2.lex}. Second part of the lexical analyzer.
	\item {\tt pfd-tokens}. The list of tokens in a {\tt PFD} file.
	\item {\tt pfd-1.y}. First part of the {\tt yacc} source.
	\item {\tt pfd-2.y}. Second part of {\tt yacc} source.
\end{enumerate}

There are also some {\tt lex} and {\tt yacc} related files to read in {\tt
AFM} files.
\begin{enumerate}
	\item {\tt afm-1.lex}. First part of the lexical analyzer.
	\item {\tt afm-2.lex}. Second part of the lexical analyzer.
	\item {\tt afm-tokens}. The list of tokens of a	{\tt AFM} file.
	\item {\tt afm-1.y}. First part of {\tt yacc} source.
	\item {\tt afm-2.y}. Second part of {\tt yacc} source.
\end{enumerate}

\section{{\tt printpdr}: Print {\tt PDR} Files}
% =============================================
	This directory contains a utility extracting the encoding vector of a \PS{} font from
a {\tt PDR} file. The generated file can be printed running it through
\LaTeX, as it done in this paper. For details see the makefile for this
paper and also \SectionRef{s-printpdr-man}, \page.

\section{{\tt man}: Manual Pages}
% ===============================
	The manual pages of the software are stored in this directory.
Observe that if you have TranScript running on your machine then the
manual pages will be included into the final document as follows. The
manual pages will be processed by {\tt ptroff} a version of {\tt troff}
generating \PS. This \PS{} output can then be included into this
document. Check {\tt setup/`hostname`/local-defs}, variable {\tt TRANSCRIPT}.

\section{{\tt doc}: Documentation Directory}
% ==========================================
	The documentation directory contains the complete documentation in
\LaTeX. Observe that various parameters must be set in {\tt
setup/`hostname`/local-defs} to the proper values.

\section{{\tt psfig}, Psfig Sources}
% ==================================
The psfig sources are contained in this directory. Note that this
directory is logically really a subdirectory of directory {\tt doc}.

\section{{\tt PFD}: Master {\tt PFD} Files}
% =========================================
	This directory contains three subdirectories in which, if {\tt make}
is executed, various standard {\tt TFM} and {\tt PDR} files are
generated by {\tt pfd2tfm}.
\begin{enumerate}
	\item {\tt extra}. Here you should add all the \PS{} fonts which you
		have bought in addition to the \PS{} fonts which are usually
		available and which are listed in the following two directories.
	\item {\tt regular}. The base set of \PS{} fonts, Helvetica*, Times*
		and Courier*; also the \PS{} Symbol font.
	\item {\tt regular-II}. The additional \PS{} fonts (additional with
		respect to the fonts contained in {\tt regular}) as they are
		available with the Apple LaserWriter~II.
\end{enumerate}

\section{Porting the Software}
% ============================
	In case you would like to port the driver to a Non-Unix Environment,
or in general to a different flavor of Unix please be aware of the
following:
\begin{itemize}
	\item The copyright mandates that you pass along the complete sources
		to anyone who receives your software.
	\item The copyright also mandates that you do not sell the software
		for profit.
	\item The copyright finally mandates that you report your results to
		the author of this software.
	\item Observe that {\tt lex} is used in the source code of the driver
		(which could be eliminated faily easily) and that {\tt yacc} and {\tt lex} are
		used in {\tt pfd2tfm} (which also could be eliminated).
	\item Note finally that {\tt pltotf} is used in {\tt pfd2tfm}.
\end{itemize}

\section{SYS V}
% =============
For System~V type of machines you must specify {\tt SYS\_V = 1} in {\tt local-defs}.
The main difference between BSD and SYS~V as far as this software is concerned
are as follows:
\begin{enumerate}
	\item {\tt string.h} must be loaded (it's {\tt strings.h} for BSD).
	\item {\tt strchr()} must be used instead of {\tt index()} in BSD.
	\item {\tt strrchr()} must be used instead of {\tt rindex()} in BSD.
\end{enumerate}