%%% File: mppicdoc.tex
%%% A part of mfpic 0.6 2002/09/12
%%%
%  More detail on some of the newer features
\input header

% For "12pt":
%\magnification=\magstep1

% Paper size: {width}{height}
\setpapersize{8.5truein}{11 truein}

% Text size: {width}{height}
\setpagegeometry{5.4167 in}{7.4166 in}

\noindent{\bf Using\/ \prog{mfpic} with \MP%
\footnote{}{\prog {mfpic} Version:  \mfpicversion.}}

\vskip\beforeskip
\noindent The \prog{mfpic} system now includes support for \MP. This
necessitated rewriting so many of the \prog{grafbase} macros that a
separate file, \file{grafbase.mp}, implements the \MP{} code while
\file{grafbase.mf} still contains the \MF{} code. This document
addresses the issues that arose with the added \MP{} support.

There were a great many changes to \file{mfpic.tex}, but I believe
we have retained backward compatibility (with versions after 0.2.10.9) in
the following senses:
\item{--} Previous files that input \file{mfpic.tex} can be processed
    with the new package. While they produce slightly different \MF{}
    code, the pictures should be the same except that some broken code
    has been fixed.
\item{--} Previous \file{.mf} files produced by \TeX{}ing the above
    files should still be correct and produce the same pictures as
    before when processed with \MF.
\item{--} Previously produced \file{.mf} files and new \file{.mf} files
    produced without turning on \MP{} support, can nevertheless be
    processed with \MP{} without error. This will not permit any of the
    \PS{} specific enhancements, and may not produce exactly the same
    picture due to essential differences between \MF's and \MP's output
    format.

However, no backward compatibility is guaranteed for \mac{mfsrc}
commands that write raw \MF{} or \prog{grafbase} code. Moreover there
has been a change in the code, beginning around version 0.3.8, so that
changes to most (all?) \prog{mfpic} parameters are local if they are
changed inside an \env{mfpic} environment. Thus, files that rely on a
change like \mac{axisheadlen}[6pt], made in one picture, persisting to
the next picture, will be broken. We think the new behavior is better,
and more in line with user expectations.

There is no change to the usage and the new \prog{mfpic} macros write
(nearly) the same \MF{} file as before. However the command
\mac{usemetapost} will cause a \file{.mp} file to be written that will
be significantly different than the \file{.mf} otherwise produced.
Running \MP{} on this file will create \EPS{} graphics files instead of
a font file. The new \prog{mfpic} now includes support for including
these graphics. Naturally, it is required that you have a system that
allows printing of \EPS{} figures. A typical system might consist of
\file{epsf.tex} and/or the \LaTeXe{} \prog{graphics} package for
graphics inclusion, plus the \prog{dvips} driver, plus either a \PS{}
printer or \GS. In addition, \pdfTeX{} and \pdfLaTeX{} can be used. See
below for more details about the requirements.

\head{Using \MP.}

The simplest way to turn on \MP{} support is to issue the command

\bex
\mac{usemetapost}
\eex

in your source file. This must come after inputting the
\prog{mfpic} macros, but before the \mac{opengraphsfile} command. In
\LaTeXe{} one can use \mac{usepackage}[?metapost][mfpic]. Changing
between \opt{metafont} and \opt{metapost} options in a single document
has not been tested and is officially unsupported.

To use \prog{mfpic} with \MP, the following support is needed (besides a
working \MP{} installation):

\vskip\myskip
\halign{#\hfil\quad&\vtop{\hsize 4.4 truein \raggedright \noindent
    \strut#\strut}\hfil\cr
Under plain\TeX           &The file \file{epsf.tex}\cr
Under \LaTeX209           &The file \file{epsf.tex} or \file{epsf.sty}\cr
Under \LaTeXe             &The package \prog{graphics} or \prog{graphicx}\cr
Under \pdfLaTeX{}         &The package \prog{graphics} or
                           \prog{graphicx} with option \opt{pdftex}\cr
Under plain \pdfTeX{}     &The files \file{supp-pdf.tex} and
                           \file{supp-mis.tex}\cr
In all cases              &The files \file{grafbase.mp} and
                           \file{dvipsnam.mp} plus, of course,
                           \file{mfpic.tex} (and \file{mfpic.sty} for
                           \LaTeX)\cr
}
\vskip\myskip
The file \file{grafbase.mp} should be in a directory searched
by \MP. The remaining files should be in directories searched by the
appropriate \TeX{} variant. At present only versions of these files and
packages current at the time of testing have been tested. If \MP{} cannot
find the file \file{grafbase.mp}, then by default it will try to input
\file{grafbase.mf}, with generally fatal results.

In case \pdfLaTeX{} is used, the graphics package should be given
the \opt{pdftex} option. This option requires the files
\file{pdftex.def}, \file{supp-pdf.tex} and \file{supp-mis.tex}. The
first of these is supplied with the \prog{graphics} package, and the
other two are usually supplied with a \pdfTeX{} distribution.

If the user explicitly inputs one of the above required files or
packages before the \prog{mfpic} macros are loaded then \prog{mfpic}
will not reload them. If they have not been input, \prog{mfpic} will
load whichever one it decides is required. In the \LaTeXe{} case,
\prog{mfpic} will load the \prog{graphics} package. If the user wishes
\prog{graphicx}, then that package must be loaded before \prog{mfpic}.
As a convenience, any options to \prog{mfpic} other than the ones it
recognizes are passed on to the \prog{graphics} package before loading
it. Therefore, the following code

\bex
    \mac{usepackage}[?dvips,metapost][mfpic]
\eex

will load the \prog{mfpic} macros, then load the \prog{graphics} package
with the \opt{dvips} option. On the other hand,

\bex
\mac{usepackage}[?dvips][graphicx]
\mac{usepackage}[?metapost][mfpic]%
\eex

is required to use the \prog{graphicx} package with the \prog{dvips}
driver option.

If \MP{} support is turned on, the user is expected to run \MP{} on the
resulting \file{.mp} file instead of \MF. A typical sequence of
operations is as follows.
\item{1.} The user creates some file \file{user.tex} which contains one
    of the above methods of invoking \MP{} support, the command
    \mac{opengraphsfile}[thefigs], and then some \mac{mfpic}
    commands or \env{mfpic} environments (followed later by
    \mac{closegraphsfile}, of course).
\item{2.} The user runs the appropriate variant of \TeX{} on
    \file{user.tex}. If all goes without error, the file
    \file{thefigs.mp} is created.
\item{3.} The user runs \MP{} on the file \file{thefigs.mp}. \MP{} inputs
    \file{grafbase.mp} containing \MP{} macros to aid in creating files
    \file{thefigs.1} through \file{thefigs.N} (where \file{N} is
    the number of figures) each containing a different \EPS{} figure.
\item{4.} The user runs \TeX{} again. It is at this stage that the figure
    inclusion is done by the appropriate macros from \file{epsf.tex} or
    the \prog{graphics} package, or the \file{supp-pdf.tex}.
\item{5.} The user runs the appropriate DVI-to-PS driver such as
    \prog{dvips}, on \file{user.dvi}, and then prints or views the
    resulting \file{user.ps} using, e.g., \GS. If \pdfTeX{} or
    \pdfLaTeX{}
    is used in step 4, a \file{.pdf} file is output instead of \file{.dvi}.
    In this case the user prints or views it with a PDF viewer.

\head{Additions.}

Invoking \MP{} support adds certain extensions to \prog{mfpic}.

\subhead{Color support}

The code in \file{grafbase.mp} keeps track of six colors:

\bex
\mfc{drawcolor}, \mfc{fillcolor}, \mfc{hatchcolor},
\mfc{headcolor}, \mfc{tlabelcolor} and \mfc{background}.
\eex

These control the colors used for drawing lines and curves,
for filling regions, for hatching the interiors of regions, for drawing
arrowheads, and for text that is placed by \MP{} (requires the
\opt{mplabels} option). The easiest way to invoke some color other than
black (the default) is via the following \prog{mfpic} macros:

\bcd
\mac{drawcolor}[\<color\>]  \\
\mac{fillcolor}[\<color\>]  \\
\mac{hatchcolor}[\<color\>] \\
\mac{headcolor}[\<color\>]  \\
\mac{tlabelcolor}[\<color\>]\\
\mac{backgroundcolor}[\<color\>]
\ecd

These commands write code into the \file{.mp} file that sets the value
of the color for the appropriate figure elements. The macro
\mac{gfill} uses the \mfc{fillcolor}. When \mac{ifpointfill} tests
true then also \mac{point} draws points in \mfc{fillcolor}. The new
macro \mac{polkadot}, draws the polkadots in \mfc{fillcolor}. All the
hatching commands \mac{xhatch}, \mac{rhatch}, etc., use
\mfc{hatchcolor}. All drawing of paths, curves, lines, etc., including
dashed and dotted lines, the shafts of arrows and the boundary of
unfilled points use \mfc{drawcolor}. All arrowheads are drawn in
\mfc{headcolor} including those created by the \mac{axes} command. All
text placed by \mac{tlabel} (and similar macros) when \opt{mplabels}
is in force will be in \mfc{tlabelcolor}. \mac{gclear} uses the color
\mfc{background} (\PS{} doesn't permit removal of ink, so filling with
the background color simulates clearing a region). Also the interior of
unfilled points is colored \mfc{background}. All colors are initialized
to black except \mfc{background} is white.

The \mac{shade} command is rather obsolete, but for backward
compatibility, it is accepted, but translated to a filling with gray.
The shade of gray is calculated from the values of \mac{shadespace}
and \mac{shadewd}, and the default values produce \mfc{0.75*white}.

A \<color\> is one of the predefined color names \mfc{black},
\mfc{white}, \mfc{red}, \mfc{green}, \mfc{blue}, \mfc{cyan},
\mfc{magenta}, or \mfc{yellow} or any legal \MP{} color expression. These
expressions resolve to a triplet of numbers separated by commas and
enclosed in parentheses. The numbers will be truncated to lie between 0
and 1. The predefine colors \mfc{black}, \mfc{white}, \mfc{red},
\mfc{green}, and \mfc{blue} resolve respectively to \mfc{(0,0,0)}
\mfc{(1,1,1)} \mfc{(1,0,0)} \mfc{(0,1,0)} \mfc{(0,0,1)}. It is legal to
add colors and multiply them by numbers. Therefore,
\mac{fillcolor}[\mfc{blue+green}] is legal and is essentially the
definition of \mfc{cyan}. The other predefined colors are \mfc{magenta =
red + blue} and \mfc{yellow = red + green}. Also valid is
\mac{fillcolor}[\mfc{0.7*white}], which gives a medium gray. In a
pinch, numbers may be used directly, as in
\mac{fillcolor}[\mfc{(1,.5,0)}], which should give some sort of orange
(depending on your display or printing device). The color
\mfc{(1,0.5,0)} is the same as \mfc{0.5*red + 0.5*yellow}. You can
darken any color by multiplying it by a number less than 1.

As a convenience several grafbase macros allow specifying color using
cmyk, RGB, graylevels, or predefined color names. Thus, all of the
following are valid \prog{mfpic} color specifications:
\mfc{cmyk(1,0.50,0,0)}, \mfc{rgb(0,.5,1)}, \mfc{RGB(0,127.5,255)},
\mfc{RoyalBlue} (the last is defined in \file{dvipsnam.mp}; all produce
the same color). The color specification \mfc{gray(.7)} is the same as
\mfc{0.7*white}. Use these, for example, as follows

\bex
\mac{headcolor}[RoyalBlue]\\
\mac{fillcolor}[cmyk(1,0.5,0.0)]
\eex

If these color setting commands are used outside any \mac{mfpic}
environment, they are global, and affect all following environments. If
they are issued inside an environment, they affect only subsequent
figure elements inside that environment.

If \MP{} support has not been selected, then these commands issue an
error message, and \prog{mfpic} then proceeds as if nothing has happened.

For \LaTeXe{} users, an alternative syntax is permitted similar to
\LaTeXe's color commands. For example:

\bex
\mac{fillcolor}[?\<model\>][\<color-spec\>]
\eex

where \<model\> is one of {\tt rgb, RGB, cmyk, named,} or {\tt gray},
and \<color-spec\> is a specification of the values appropriate to the
model. For example:

\bex
\mac{hatchcolor}[?cmyk][0,.8,.6,.2]
\eex

This example is equivalent to \mac{hatchcolor}[cmyk(0,.8,.6,.2)]

If the {\tt named} model is used, the name specified must be a
previously defined color name, either one of the predefined names, or a
name defined in \file{dvipsnam.mp}, or one defined by
the following command:

\bex
\mac{mfpdefinecolor}[\<name\>][\<model\>][\<color-spec\>]
\eex

This will define a named color. Its use is best illustrated by an
example, After

\bex
\mac{mfpdefinecolor}[DarkPuce][rgb][.8,.12,.56]
\eex

then one may use any of the following, with the same effect:

\bex
\mac{drawcolor}[?named][DarkPuce]  \par
\mac{drawcolor}[?rgb][.8,.12,.56] \par
\mac{drawcolor}[rgb(.8,.12,.56)]  \par
\mac{drawcolor}[DarkPuce]
\eex

\subhead{Color options}

For more control over color of individual elements, the macros
\mac{gfill} and \mac{draw} have been given optional arguments for
specifying the color. In addition \mac{point} and the hatching macros
now have a second optional argument for specifying the color, and the
\mac{arrow} macro has another optional argument (now four altogether)
for determining the color of the head.

This optional color will be used for the single element only and has no
effect on \mfc{fillcolor}, \mfc{drawcolor}, \mfc{hatchcolor}, or
\mfc{headcolor}. See \file{mfpicdoc.tex} for the syntax of the color
options.


Here is an example mixing these different methods of changing
color:

\bex
\mac{hatchcolor}[green]\\
\mac{draw}[?blue]\mac{hatch}\mac{gfill}[?red]\\
\mac{circle}[(0,0),2]
\eex

This will draw a red filled, green hatched, blue
circle. At the moment, the \mac{dashed} and \mac{dotted} commands do
not have new color options. Use something like the following:

\bex
\mac{drawcolor}[blue]\\
\mac{dotted}\mac{gfill}[?red]\mac{circle}[(0,0),2]\\
\mac{drawcolor}[black]
\eex

to fill a circle with red, and outline it with a dotted blue
boundary, returning to a default black.

\subhead{Cautions.}

\PS{} is not a pixel oriented language and so neither is \MP. The model
for drawing objects is completely different between \MF{} and \MP, and so
one cannot always expect the same results. \MP{} support in \prog{mfpic}
was carefully written so that files successfully printed with
\prog{mfpic} using \MF{} would be just as successfully printed using \MP.
Nevertheless, it will almost certainly choke on files that make use of
the \mac{mfsrc} command for writing code directly to the \file{.mf}
file. While \file{grafbase.mp} is closely based on \file{grafbase.mf},
much of the code had to be completely rewritten.

Pictures in \MP{} are stored as (possibly nested) sequences of objects,
where objects are things like points, paths, contours, other pictures,
etc. In \MF, pictures are stored as a grid of pixels. Thus, pictures
that are relatively simple in one program might be very complex in the
other and even exceed memory allocated for their storage. A case in
point is the \mfc{shade} command in \file{grafbase.mf}. The \MF{} code
simply added regularly spaced dots (which each contained typically about
4 pixels at the resolution 300dpi) to the interior of a contour.
Essentially the same code in \MP{} creates a picture containing an
extremely large number of tiny circles, stored as filled cyclic contours
with eight nodes each. Even modest sized regions with modest values of
\mac{shadespace} overflowed the \MP{} capacity in two of the
distributions tested. In addition, the resulting shading tended to be of
very low quality when viewed or printed with the software we tested.
Therefore, the \mac{shade} macro under the \prog{metapost} option merely
fills with a gray color calculated to be black if the shading space is
not larger than the size of the dots. Keeping \mac{shade} at all was
done purely for backward compatibility since \mac{gfill} now has a color
option for \MP.

A model that helped me in developing the \MP{} macros for \PS{} support is
as follows. Think of each figure element as being painted on a
transparent sheet. The final picture is obtained by laying each sheet
on top of the previous sheets in the order they are drawn. In this model,
the sheets are transparent, but the paint is opaque. This leads to some
problems. For example, paint cannot be removed%
\footnote{$^*$}{The \mac{gclip} command would seem to contradict this,
but what \MP{} actually does with that command is to give the picture
the attribute of being clipped. In the \PS{} output, a clipping path is
defined, and the paint outside that path is never laid down. Still, one
can think of this as the exception from the point of view of
\prog{mfpic}.}%
, it can only be covered up. Therefore the code for \emph{unfilling} a
region is really just painting over in the color  \mfc{background}. This
background color is still opaque, so if you create a picture of an
annulus by filling a circle and then unfilling a smaller circle, the
center ``hole'' is not really a hole. Placing this picture on top of
another will obscure everything, nothing will show through the hole. In
\MF, the aforementioned annulus can be obtained by simply zeroing the
pixels in the smaller circle. Adding this on top of another picture will
allow anything in the hole to show through.

Therefore, the order in which picture elements are added is of great
importance. In \env{mfpic} environments, figures are drawn in the order
they are written. But when prefix macros \emph{add} elements to a curve,
these elements are drawn in reverse order.%
\footnote{$\dag$}{In programming terms, prefixes are \emph{right
associative}.}
For example, \mac{rect}[(0,0),(1,1)] simply draws a square with line
thickness equal to the default pen width. And
\mac{gfill}\mac{rect}[(0,0),(1,1)] draws only the filled interior of
that square. But \mac{draw}\mac{gfill}\mac{rect}[(0,0),(1,1)] fills the
interior, and \emph{then} draws the boundary. Part of the filled
interior is covered by the pen stroke (the filling is done right up to
the boundary, the pen is stroked with its center along the boundary).
This usually gives the best picture when the interior and boundary are
different colors. On the other hand,
\mac{gfill}\mac{draw}\mac{rect}[(0,0),(1,1)]
draws the boundary and \emph{then} fills the interior. Part of the
boundary stroke (half its thickness) is covered by the filling painted
over it. This covering makes no difference when all the colors are the
same (black), but now that colors are introduced it can make a big
difference in the final picture. Placing prefixes in the following order
(any prefix could be absent) should have most pictures looking best:
\item{--} Any arrow drawing prefixes first. Arrows are drawn with a
        simple \mac{arrow} or with \mac{arrow}\mac{reverse} or
        \mac{arrow}\mac{reverse}\mac{arrow}
\item{--} Any prefix for dashing, dotting or drawing the curve next.
        These include \mac{dashed}, \mac{dotted}, and \mac{draw}.
\item{--} Any hatching prefix or \mac{polkadot} next. If both are
        used, the one you want on top should be first.
\item{--} Any filling prefix next (\mac{shade} or \mac{gfill}).
\item{--} Any transformation prefix (such as \mac{rotatepath}) or
          closing prefix (like \mac{lclose}) next, immediately before the
          curve. The order of these is not important.
\item{--} The curve (or a set of curves in a \mac{connect}
          group) last.

The placement of transformation macros (like \mac{rotatepath}) depends
on what effect you want to achieve. Something like

\bex
\mac{draw}\mac{rotatepath}[(0,0),45]\mac{shade}\mac{rect}[(0,0),(1,1)]
\eex

will shade the original rectangle, but draw the outline of the rotated
version. If you want just one rectangle with various additions, put the
transformation macro right before the figure macro.

The definition of \mac{shade} as a gray fill means that old
\file{.tex} files using \prog{mfpic} might need to be edited. The
position of \mac{shade} among the prefixes might need to be changed,
or a shaded figure might need to be drawn first so that other curves are
not completely covered up.

\subhead{Text Manipulations}

If text is placed by \MP{} using the \opt{mplabels} option, then text
may be rotated. One might conceivably perform other transformtions, but
that has not (yet) been implemented.

\head{Other Considerations}

It may be impossible to completely cater to all possible methods of graphic
inclusions with automatic tests. The macro that actually causes the \PS{}
graphic to be included is \mac{setmfpicgraphic}, and the user may
(carefully!) redefine this to suit special circumstances. The following
are the default definitions.

\vskip\myskip
\halign{#:\hfil&\quad#\hfil\cr
In plain TeX&
\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl epsfbox\{\#1\}\}\cr
In \LaTeX209&
\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl epsfbox\{\#1\}\}\cr
In \LaTeXe&
\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl includegraphics\{\#1\}\}\cr
In \pdfLaTeX&
\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl includegraphics\{\#1\}\}\cr
In \pdfTeX&
\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl convertMPtoPDF\{\#1\}\{1\}\{1\}\}\cr
}
\vskip\myskip
Moreover, since \MP{} by default writes files with numeric extensions,
we add code to each figure, so that these graphics are correctly
recognized as \EPS{} or {\sc MPS}. For example, to the figure with
extension \file{.1}, we add the equivalent of one of the following
\item{} {\tt \bsl DeclareGraphicsRule\{.1\}\{eps\}\{.1\}\{\}} in \LaTeXe.
\item{} {\tt \bsl DeclareGraphicsRule\{.1\}\{mps\}\{.1\}\{\}} in \pdfLaTeX.

Also, after running the command \mac{setmfpicgraphic}, \prog{mfpic}'s
figure placement code runs \mac{getmfpicoffset} to store the lower left
corner of the bounding box of the figure in two macros \mac{mfpicllx}
and \mac{mfpiclly}. All the above definitions of \mac{setmfpicgraphic},
except \mac{includegraphics}, make this information available, and the
definition of  merely copies it into these two macros. What \prog{mfpic}
does in the case of \mac{includegraphics} is to modify (locally) the
definition of an internal command of the graphics package so that it
copies the information to those macros, and then \mac{getmfpicgraphic}
does nothing. Changes to \mac{setmfpicgraphic} might require changing
\mac{getmfpicoffset}

One possible reason for wanting to redefine \mac{setmfpicgraphic} might
be to rescale all pictures. This is definitely not a good idea without
the option \opt{mplabels} since the \prog{mfpic} code for placing labels
and captions and reserving space for the picture relies on the picture
having the dimensions given by the arguments to the \mac{mfpic} command.
With \opt{mplabels} plus \opt{truebbox} it will probably work, but
(i)~it has \emph{not} been considered in writing the \prog{mfpic} code,
(ii)~it will then scale all the text as well as the figure, and (iii)~it
will scale all line thickness, which should be a design choice
independent of the size of a picture. To rescale all pictures, one need
only change \mac{mfpicunit} and rerun \TeX{} and \MP.

A better reason might be to allow the conversion of your \MP{} figures
to some other format. Then redefining \mac{setmfpicgraphic} could enable
including the appropriate file in the appropriate format.

The argument of the \mac{setmfpicgraphic} command is the filename
resulting from running the macro \mac{setfilename}. The command
\mac{setfilename} gets two arguments: the name of the \MP{} output file
(set in the \mac{opengraphsfile} command) without extension, and the
number of the picture. The default definition of \mac{setfilename}
merely inserts a dot between the two arguments. That is
\mac{setfilename}[fig][1] produces \file{fig.1}. You can redefine this
behavior also. Any changes to \mac{setfilename} must come after the
\prog{mfpic} macros are input and before the \mac{opengraphsfile}
command. Any changes to \mac{setmfpicgraphic} must come after the
\prog{mfpic} macros are input and before any \mac{mfpic} commands, but
it is best to place it before the \mac{opengraphsfile} command.

As a hypothetical example, let us say you run \TeX{} on your source file,
producing \file{fig.mp}, and then you run \MP, producing \file{fig.1}
through \file{fig.10}. Now you convert them to some hypothetical format
\file{fig-1.pxy} through \file{fig-10.pxy}. You could then do something
like the following:

\bex
{\tt \bsl def\bsl setfilename\#1\#2\{\#1-\#2.pxy\}}\\
{\tt \bsl def\bsl setmfpicgraphic\#1\{\bsl includepxy\{\#1\}\}}
{\tt \bsl def\bsl getmfpicoffset\#1\{$<{\it code}>$\}}
\eex
and the figures will be automatically included (assuming that the
hypothetical command \mac{includepxy} can include the hypothetical
graphics format \file{pxy} and that $<{\it code}>$ saves the lower left
corner of the bounding box of \file{.mp} in the appropriate macros).
However you define \mac{setfilename}, it must produce the result without
assignments or side effects. (In technical terms it must be
\emph{completely expandable.}) Something that is very difficult without
assignments is to change the number, like trying to get
\mac{setfilename}[file][\<$n$\>] to produce \file{file.\<$n+1$\>}. I
don't recommend trying this. Instead, use \mac{mfcpicnumber}[2] before
the \mac{opengraphsfile} command to start the figure numbering from 2.


Some figure inclusion macros (such as \mac{epsfbox} from
\file{epsf.tex}) generate rather large amounts of error messages for
nonexistent figure files, so \prog{mfpic} tests for the existence of the
file before attempting an inclusion. Therefore,
\mac{setfilename}[\#1][\#2] should produce the actual name of the
necessary file when {\tt \#1} is the name supplied in the
\mac{opengraphsfile} command and {\tt \#2} is the number of the
\env{mfpic} environment.

The code in \prog{mfpic} detects the \TeX{} format in the following way:
If \mac{documentclass} is a defined command, \LaTeXe{} or \pdfLaTeX{} is
assumed. If not, but \mac{documentstyle} is defined and \mac{fmtname} is
not {\tt AmS-TeX}, \LaTeX209 is assumed. If \mac{pdfoutput} is defined
and has a non-zero value, \pdfLaTeX{} or \pdfTeX{} is assumed.

\head{Files}

The current version of \prog{mfpic}, consists of five files exclusive of
documentation and tests. The files \file{grafbase.mp} and
\file{grafbase.mf} contain the basic \MP{} and \MF{} macros, the file
\file{dvipsnam.mp} contains the \MP{} definitions of 68 color names. The
file \file{mfpic.tex} contains all the essential \TeX{} macros. The file
\file{mfpic.sty} simply issues \mac{input mfpic.tex}.

The plain ASCII file \file{readme.1st} should be (should have been!)
read first. The file \file{manifest.txt} contains the full list of files
with an indication of the purpose of each.

\bye
