⟦6b919b3db⟧

TextFile

\chapter{Problems and Extensions}
% ===============================
\label{c-extensions}

	In this chapter I will discuss some of the possible extensions and
improvements which could be made to this software.  If someone
is interested in me doing those extensions please send me a purchase
order and I'll do it.

\section{A Cluge in the Driver}
% =============================
	I have not yet figured out the reason why \verb+$\longleftarrow$+
generates an arrow where the short arrow and the line which extends the
short arrow to make it a long one do not lign match.  I looked at the pixel patterns sent to
the printer and they seem to be ok.

	I finally inserted a fix into {\tt dvitps/src/shipc.c}.
But this fix makes no sense whatsoever: {\tt yoff} is correctly set but must
be incremented by one for printing purposes! Anybody any idea?

\section{Math Mode using \PS{} Fonts}
% ===================================
	I never thoroughly investigated the issue of using \PS's Symbol Font for
mathematical equations. But it is fair to say that this
font could not be used to typeset all mathematical equations. How it
could be made to typeset some of the equations at least I have never
investigated thoroughly. It did not seem worth the effort as far as I am
concerned.

\section{\LaTeX's Picture Environment}
% ====================================
	The picture environment of \LaTeX{} could be modified to generate
\PS{} core directly. This would eliminate many of the limitations, in
particular the limitations on the sizes of circles and the slopes of
lines. Somebody may want to implement that.

\section{\LaTeX{} and \protect\PS{} Fonts}
% ========================================
	It would be nice to define style files which use the \PS{} fonts.
Anybody?

\section{\protect\PS{} Font Modifications}
% ========================================
	The following modifications to \PS{} fonts are feasible in \PS{} and
these modifications could be added to the driver and {\tt pfd2tfm}:
\begin{enumerate}
	\item Mono case (also called small caps) versions of \PS{} fonts.
	\item Outline \PS{} fonts. If you consult the \PS{} manuals then you will
		realize that an outline format of the \PS{} fonts exists. {\tt
		pfd2tfm} and the driver could be extended in this sense.
\end{enumerate}

\section{Font File Searching}
% ===========================
The current version of the program essentially assumes that all fonts
reside in one directory. There is a lot to be said about allowing the
fonts to be stored in separate directories. For instance, one could have
a directory for all {\tt cmr10} font related files, another one for {\tt
cmr12}, or combine all {\tt cmr} fonts into one directory.

	There are many possibilities.  I did not implement any of those
schemes. If somebody is interested in doing so I will be more than happy
to integrate his or her work and send out any changes.

	Looking through my electronic mail I found a note from Thomas Reid
which I will reprint in full length here, simply because he really
thought about the problem and this message could be used by the person
who decides to extend the driver.

	Here is the message:
\btex
Return-Path: <purdue!@VM.CC.PURDUE.EDU:DRIV-L@TAMVM1.BITNET>
Date:         Fri, 26 May 89 11:30:34 CDT
Reply-To: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
Sender: The TUG DVI driver standards discussion list <purdue!TAMVM1!DRIV-L>
From: "Thomas J. Reid" <purdue!TAMVM1!X066TR>
Subject:      File naming conventions
To: Stephan von Bechtolsheim <purdue!svb>

I agree with Jerry Leichter that a control string is a good way for
those installing drivers to control the naming conventions for files.
It is also important to have a convention which allows multiple
directories to be searched so that users can have their own private
font (or whatever) directories and to be able to access file servers in
distributed systems (as Jerry also indicates).

I have a very generalized name building routine implemented in my driver,
TeXrox.  I found it necessary to do this because my driver runs on
UNIX, VAX/VMS, VM/CMS, MVS, and AOS/VS and the file name formats are
quite different between these systems.

First, let me give sample names which we are using here for PK and TFM
files under these different systems:

   UNIX:     /tex/fonts/bitmaps/xerox4050/cmr10.300pk
             /tex/fonts/bitmaps/xerox4050/cmr10.329pk
             /tex/fonts/metrics/cmr10.300pk

   VAX/VMS:  TeX_Xerox4050_Fonts:CMR10.300PK
             TeX_Xerox4050_Fonts:CMR10.329PK
             TeX_Font_Metrics:CMR10.TFM

   VM/CMS:   CMR10 300PK *
             CMR10 329PK *
             CMR10 TFM *

   MVS:      PK300(CMR10)
             PK329(CMR10)
             TFM(CMR10)

   AOS/VS:   :FONTS:PK_W300:CMR10.0PK
             :FONTS:PK_W300:CMR10.HPK
             :FONTS:TFM:CMR10.TFM

These names reflect the current conventions which we are using.

Each of these names are made up from several different types of components:

   * Fixed character strings such as "/tex/fonts"
   * File names such as "cmr10" or "CMR10"
   * Magnifications such as "1500" and "1643" (for 300 dpi devices)
   * Resolutions such as "300" and "329"
   * Magstep codes such as "0" and "H"
   * Driver- and device-specific codes such as "Xerox4050" and "Xerox9700".


File name configuration strings
-------------------------------

My implementation uses several "environment variables" (logicals under
VMS) as well as some installation-defined patterns.  The configuration
strings for each of the five systems are:

   UNIX:     PathDelimiter     ":"
             PathEscape        "%"
             TeXdirectory      "/tex"
             PKfilePrototype   "%f.%rpk"
             PKsearchPath      "%a:.:%t/fonts/bitmaps/%p"
             PKuserVariable    "TEXPKPATH"
             TFMfilePrototype  "%f.tfm"
             TFMsearchPath     "%a:.:%t/fonts/metrics"
             TFMuserVariable   "TEXTFMPATH"

   VAX/VMS:  PathDelimiter     ","
             PathEscape        "%"
             TeXdirectory      "TeX_Root:[000000]"
             PKfilePrototype   "%F.%RPK"
             PKsearchPath      "%A,,TeX_%P_Fonts:"
             PKuserVariable    "TeXrox_PK_Path"
             TFMfilePrototype  "%F.TFM"
             TFMsearchPath     "%A,,TeX_Font_Metrics:"
             TFMuserVariable   "TeXrox_TFM_Path"

   VM/CMS:   PathDelimiter     ""
             PathEscape        "%"
             TeXdirectory      ""
             PKfilePrototype   ""
             PKsearchPath      "%8 %RPK *"
             PKuserVariable    ""
             TFMfilePrototype  ""
             TFMsearchPath     "%8 TFM *"
             TFMuserVariable   ""

   MVS:      PathDelimiter     ""
             PathEscape        "%"
             TeXdirectory      ""
             PKfilePrototype   ""
             PKsearchPath      "PK%R(%8)"
             PKuserVariable    ""
             TFMfilePrototype  ""
             TFMsearchPath     "TFM(%8)"
             TFMuserVariable   ""

   AOS/VS:   PathDelimiter     ","
             PathEscape        "%"
             TeXdirectory      ":FONTS"
             PKfilePrototype   "%F.%MPK"
             PKsearchPath      "%A,,%T:PK_W300"
             PKuserVariable    "TEXPKPATH"
             TFMfilePrototype  "%F.TFM"
             TFMsearchPath     "%A,,%T:TFM,%T:XRX_TFM"
             TFMuserVariable   "TEXTFMPATH"

(There are actually several other variables for other file types including
GF and PXL files but they are all variations of what is shown here.)

The variable parts within the name templates are indicated by "%" followed
by a single character code.  (The percent is also variable.)  The codes
are:

      %a     Area name from DVI file.  This is non-null if the user has
             something like "\font\test=/tsg/pixeldoc/texfonts/cmr10" in
             the input file.  The area name is "/tsg/pixeldoc/texfonts/".
      %A     Area name in uppercase.  I have separate codes for this even
             though for all the systems which I am presently using which
             ignore case, the name does not have to be in uppercase.

      %f     The font name from the DVI file such as "cmr10"
      %F     The font name from the DVI file converted to uppercase.
      %8     The font name truncated to 8 characters.

   %s or %S  The scaling factor of the font such as 1500, 1643, etc

      %m     The magstep number (0, h, 1, 2, 3, 4, 5, 6, 7, 8, or 9)
      %M     The magstep number (0, H, 1, 2, 3, 4, 5, 6, 7, 8, or 9)

   %r or %R  The resolution of the font (300, 329, 360, etc.)
   %p or %P  The "print mode" string (Xerox4050 or Xerox9700 for us)
   %t or %T  The TeX home directory as defined by the TeXdirectory option.
   %d or %D  Default search path (used by the user as shown below)

When processing names, my driver extracts each name template from the
PKsearchPath and TFMsearchPath options and appends the PKfilePrototype
or TFMfilePrototype option string if none of %f, %F, or %8 is used.  For
UNIX and AOS/VS, directory delimiters are placed between the two strings.
Thus, the following names are searched for PK files:

   UNIX:     %a/%f.%rpk                     look in specified directory
             ./%f.%rpk                      look in user's current direct.
             /tex/fonts/bitmaps/%p/%f.%rpk  look in system directory

   VAX/VMS:  %A%F.%RPK                      look in specified directory
             %F.%RPK                        look in user's current direct.
             TeX_%P_Fonts:%F.%RPK           look in system directory

   VM/CMS:   %8 %RPK *    "*" means search all accessed "minidisks"

   MVS:      PK%R(%8)     look for member in library(ies) defined on
                          "PK300", "PK329", etc. "DD statements"

   AOS/VS:   %A:%F.%MPK                     look in specified directory
             %F.%MPK                        look in user's current direct.
             :FONTS:PK_W300:%F.%MPK         look in system directory

The file names are searched for in the order indicated.  This allows users
to make use of the "area" name option on a \font command and to have
their own fonts in their current directory.  If users wish to have their
own private font directories, environment variables can be used (under
UNIX, VAX/VMS, and AOS/VS) to override the search procedure.  For instance,
under VAX/VMS, I could use the DCL command:

   DEFINE TeXrox_PK_Path "SYS$USERDISK2:[TJR6743.FONTS],%D"

to cause the driver to first look for fonts under:

   SYS$USERDISK2:[TJR6743.FONTS]%F.%RPK

before following the default search procedure.  (Placing "%D," before
the SYS$... stuff would cause the default names to be searched for before
looking in my private directory.)


Implementation
--------------

The file name building is implemented in two phases:  During initialization
of the driver, the XXsearchPath, XXuserVariable, and XXfilePrototype options
are split into the individual file name templates and preprocessed.  A C
structure as follows:

   struct name_format {
        struct name_format *next_ptr;
        short part_index[10];
        char *format;
   };

   struct name_format *name_entry;

is allocated and defined with the 10 part_index entries being set to an
integer representing what should be substituted in the string (area name,
AREA NAME, etc.) and format pointing to an sprintf string with "%s"es
replacing each of the "%a"s, "%A"s, etc.

When a name is needed, a call is made to the name builder with name_entry,
area name, font name, and scale factor passed as arguments.  For TFM files,
zero is passed for a scaling factor.  The name builder constructs all name
components in work areas and places their addresses in:

   char *name_part[NUM_NAME_PARTS];

The integer codes stored in part_index are actually subscripts into this
name_part array which allows the file name to be built with the single
sprintf statement:

   (void) sprintf (file_name, name_entry->format,
        name_part[name_entry->part_index[0]],
        name_part[name_entry->part_index[1]],
        name_part[name_entry->part_index[2]],
        name_part[name_entry->part_index[3]],
        name_part[name_entry->part_index[4]],
        name_part[name_entry->part_index[5]],
        name_part[name_entry->part_index[6]],
        name_part[name_entry->part_index[7]],
        name_part[name_entry->part_index[8]],
        name_part[name_entry->part_index[9]]);


Conclusion
----------

Although this name building procedure is fairly complex, it is quite
general and relatively easy for a person who is installing the driver
to customize.  It permits multiple directories to be searched and gives
control over the order in which they are searched.  It can also handle
magnification expressed as a scale factor, a resolution, or a magstep
"number."  Finally, some control is given to the user so that private
font libraries can be used.

Defining guidelines for those who maintain TeX files would be helpful.
To make this most effective, I think that we should enlist the help of
the official XXX-OS TeX Site Coordinators.  This way, we could have
operating system-dependent guidelines.

However, it is still important for device drivers to have procedures for
adjusting to different naming conventions.  This is especially important
for drivers which run under multiple operating systems.

---Tom Reid
\etex

\section{Other Modifications}
% ===========================
	The following additional modifications come in mind:
\begin{enumerate}
	\item Additional parameterizations of the driver could be done in {\tt
		dvitpscap}, instead of at compile time. So far {\tt dvitpscap}
		only contains information about what font files the driver is
		looking for and in which order.
\end{enumerate}

\section{Known Problems}
% ======================
	Here is a brief list of known problems. Nothing big, I just thought
it should be mentioned.
\begin{enumerate}
	\item The driver assumes, that the boundaries given
		in {\tt GF} files ({\tt max\_h} etc.) are indeeded
		tight. This is not a practical problem, because \MF{} generates {\tt GF}
		files with tight bounds.  It is a theoretical problem though in the
		sense that {\tt GF} files generated in a different way could generate non-tight bounds, and
		the driver would not find out about it. Then pixel patterns
		larger than necessary would be sent to the printer.
	\item Rounding errors in the computation of
		file extensions for {\tt PXL}, {\tt GF} and	{\tt PK} files
		are ``fixed'' using a table. This table is specific to the
		resolution of 300 dots/inch. A more general solution would be to
		have the program actively search for the font files ``in the
		neighborhood'' of the {\it computed\/} file extension.
\end{enumerate}
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦6b919b3db⟧ TextFile

Derivation

TextFile
