This chapter gives an overview of what you do to create fonts using these programs. It also describes some things which are common to all the programs.
Throughout this document, we refer to various source files in the implementation. If you can read C programs, you may find these references useful as points of entry into the source when you are confused about some program's behavior, or are just curious.
Following is a pictorial representation of the typical order in which these programs are used, as well as their input and output.
GSrenderfont is not in the picture since it is intended for an entirely separate purpose (namely, making bitmaps from PostScript outlines). Fontconvert also has many functions which are not needed for the basic task of font creation from scanned images.
---------------
| fontconvert |
/ ---------------
/--------/ ^
scanned / |
image / v
and IFI ----------- GF ------------- TFM, GF -------- BZR
========> | imageto | ======> | charspace | =========> | limn | ======...
^ ----------- ------------- ^ --------
| / | (continued)
v CMI v
------------- --------
| imgrotate | | xbfe |
------------- --------
Metafont source ------ GF, TFM
|=====================> | mf | =========
(continued) | ------
|
BZR --------- TFM, | PostScript Type 1 (gsf)
... ======> | bzrto |========|=======================
--------- |
/ |
CCC | PostScript Type 3 (pf3)
|======================
|
|
| BPL ------------ BZR
|=========> | bpltobzr | =====
------------
See section File formats, for more information on these file formats.
The previous section described pictorially the usual order in which these programs are used. This section will do the same in words.
Naturally, you may not need to go through all the steps described here. For example, if you are not starting with a scanned image, but already have a bitmap font, then the first step--running Imageto--is irrelevant.
Here is a description of the usual font creation process, starting with a scanned image of a type specimen and ending with fonts which can be used by Ghostscript, TeX, etc.
\table
or \sample commands to produce a font table. Next, print or
preview the DVI file that TeX outputs, as before. This will probably
reveal problems in your IFI file, e.g., that not all the characters are
present, or that they are not in the right positions. So you need to
iterate until the image is correctly processed.
`testfont.tex' should have come with your TeX distribution. If
for some reason you do not have it, you can use the one distributed in
the `data' directory.
mode of whatever
device you wish (the mode localfont will get you the most
common local device, if Metafont has been installed properly). Then you
can use `testfont.tex' to get a font sample, as described above.
To do the latter, run Metafont with no assignment to mode. This
should get you proof mode. You can then use GFtoDVI to get a DVI
file with one character per page, showing you the control points Limn
chose for the outlines.
This section gives a real-life example of font creation for the Garamond roman typeface, which we worked on concomitantly with developing the programs. We started from a scanned type specimen of 30 point Monotype Garamond, scanned using a Xerox 9700 scanner loaned to us from Interleaf, Inc. (Thanks to Paul English and others at Interleaf for this loan.)
imageto -strips ggmr.img fontconvert -tfm ggmrsp.1200 echo ggmrsp | tex strips.tex xdvi -p 1200 -s 10 strips.dvi
ASCII encoding.
imageto -print-guidelines -print-clean-info -encoding=gnulatin ggmr.img
.notdef lines to `ggmr.ifi' as appropriate.
imageto -verbose -baselines=121,130,120 \ -designsize=30 -encoding=gnulatin ggmr.img
fontconvert -verbose -gf -tfm -filter-passes=3 -filter-size=3 \ ggmr30.1200 -output=ggmr30a
charspace -verbose -cmi=ggmr.1200cmi ggmr30a.1200 -output=ggmr30b
limn -verbose -corner-surround=4 -filter-surround=6 \ -filter-alternative-surround=3 -subdivide-surround=6 \ -tangent-surround=6 ggmr30b.1200
bzrto -verbose -metafont ggmr30b -output=ggmr30B mf '\mode:=localfont; input ggmr30B' echo ggmr30B | tex sample dvips sample
fontconvert -verbose -gf -tfm -designsize=26 ggmr30b.1200 -output=ggmr26c
proof mode, followed by GFtoDVI, so we could
see how well Limn did at choosing the control points for the outlines.
See section Proofing with Metafont. (The nodisplays tells Metafont
not to bother displaying each character in a window online.)
mf '\mode:=proof; nodisplays; input ggmr26D' gftodvi ggmr26D.3656gf
Since these programs do not have counterparts on historical Unix
systems, they need not conform to an existing interface. We chose to
have all the programs use the GNU function getopt_long_only to
parse command lines.
As a result, you can give the options in any order, interspersed as you wish with non-option arguments; you can use `-' or `--' to start an option; you can use any unambiguous abbreviation for an option name; you can separate option names and values with either `=' or one or more spaces; and you can use filenames that would otherwise look like options by putting them after an option `--'.
By convention, all the programs accept only one non-option argument, which is taken to be the name of the main input file.
If a particular option with a value is given more than once, it is the last value which is used.
For example, the following command line specifies the options `foo', `bar', and `verbose'; gives the value `abc' to the `baz' option, and the value `xyz' to the `quux' option; and specifies the filename `-myfile-'.
-foo --bar -verb -abc=baz -quux karl -quux xyz -- -myfile-
By convention, all the programs accept only one non-option argument, which they take to be the name of the main input file.
Usually this is the name of a bitmap font. By their nature, bitmap fonts are for a particular resolution. You can specify the resolution in two ways: with the `-dpi' option (see the next section), or by giving an extension to the font name on the command line.
For example, you could specify the font foo at a resolution of
300dpi to the program program in either of these two ways
(`$ ' being the shell prompt):
$ program foo.300 $ program -dpi=300 foo
You can also say, e.g., `program foo.300gf', but the `gf' is ignored. These programs always look for a given font in PK format before looking for it in GF format, under the assumption that if both fonts exist, and have the same stem, they are the same.
If the filename is absolute or explicitly relative, i.e., starts with `/' or `./' or `../', then the programs do not use search paths to look for it, as described in section Font searching. Instead, the fonts are simply searched for in the given directory.
Certain options are available in all or most of the programs. Rather than writing identical descriptions in the chapters for each of the programs, they are described here.
This first table lists common options which do not convey anything about the input. They merely direct the program to print additional output.
This second table lists common options which change the program's behavior in more substantive ways.
start-end'
Most of the programs allow you to specify character codes for various purposes. Character codes are always parsed in the same way (using the routines in `lib/charcode.c' and `lib/charspec.c').
You can specify the character code directly, as a numeric value, or indirectly, as a character name to be looked up in an encoding vector.
If a string being parsed as a character code is more than one character long, or starts with a non-digit, it is always looked up as a name in an encoding vector before being considered as a numeric code. We do this because you can always specify a particular value in one of the numeric formats, if that's what you want.
The encoding vector used varies with the program; you can always define an explicit encoding vector with the `-encoding' option. If you don't specify one explicitly, programs which must have an encoding vector use a default; programs which can proceed without one do not. See section Encoding files, for more details on encoding vectors.
As a practical matter, the only character names which have length one are the 52 letters, `A'--`Z', `a'--`z'. In virtually all common cases, the encoding vector and the underlying character set both have these in their ASCII positions. (The exception is machines that use the EBCDIC encoding.)
The following variations for numeric character codes are allowed. The examples all assume the character set is ASCII.
Character codes must be between zero and 255 (decimal), inclusive.
The programs have a few common conventions for how to specify option values that are more complicated than simple numbers or strings.
Some options take not a single value, but a list. In this case, the individual values are separated by commas or whitespace, as in `-omit=1,2,3' or `-omit="1 2 3"'. Although using whitespace to separate the values is less convenient when typing them interactively, it is useful when you have a list that is so long you want to put it in the file. Then you can use `cat' in conjunction with shell quoting to get the value: `-omit="`cat file`"'.
Other options take a list of values, but each value is a keyword and a corresponding quantity, as in `-fontdimens name:real,name,real'.
Finally, a few options take percentages, which you specify as an integer between 0 and 100, inclusive.
These programs use the same environment variables and algorithms for finding font files as does (the Unix port of) TeX and its friends.
You specify the default paths in the top-level Makefile. The
environment variables TEXFONTS, PKFONTS, TEXPKS,
and GFFONTS override those paths. Both the default paths and the
environment variable values should consist of a colon-separated list of
directories.
Specifically, a TFM file is looked for along the path specified by
TEXFONTS; a GF file along GFFONTS, then TEXFONTS; a
PK file along PKFONTS, then TEXPKS, then TEXFONTS.
A leading or trailing colon in an environment variable value is replaced by the default path.
A leading `~' or `~user' in a path component is replaced by the current home directory or user's home directory, respectively.
If a directory in a path does not exist, it is simply ignored.
In either the default value or the environment variable value, if a component directory d ends with two slashes, all subdirectories of d are searched: first those subdirectories directly under d, then the subsubdirectories under those, and so on. At each level, the order in which the directories are searched is unspecified.
The subdirectory searching has one known deficiency, for which we know
of no good solution. If a directory d being searched for
subdirectories contains plain files and symbolic links to other
directories, but no real subdirectories, d will be considered a
leaf directory, i.e., the symbolic links will not be followed. The only
way we know of to fix this is to invoke stat (an expensive system
call) on every directory entry. Since font directories often contain
hundreds of files, this would make the startup time unacceptably slow.
A directory d explicitly named with two trailing slashes, however, is always searched for subdirectories, even if it is a "leaf". We do this since presumably you would not have asked d to be searched for subdirectories if you didn't want it to be, and therefore you don't have hundreds of files in d.
For example, the following value for an environment variable says to search the following: all subdirectories of the current user's `fonts' directory in his or her home directory, then the directory `fonts' in the user `karl's home directory, and finally the system default directories specified at compilation time.
~/fonts//:~karl/fonts:
Naming font files has always been a difficult proposition at best. On the one hand, the names should be as portable as possible, so the fonts themselves can be used on almost any platform. On the other hand, the names should be as descriptive and comprehensive as possible. The best compromise we have been able to work out is described in a separate document: section `Introduction' in Filenames for TeX fonts. See section Archives, for where to obtain.
Filenames for GNU project fonts should start with `g', for the "source" abbreviation of "GNU".
Aside from a general font naming scheme, when developing fonts you must keep the different versions straight. We do this by appending a "version letter" `a', `b', ... to the main bitmap filename. For example, the original Garamond roman font we scanned was a 30 point size, so the main filename was `ggmr30' (`g' for GNU, `gm' for Garamond, `r' for roman). As we ran the font through the various programs, we named the output `ggmr30b', `ggmr30c', and so on.
Since the outline fonts produced by BZRto are scalable, we do not include the design size in their names. (BZRto removes a trailing number from the input name by default.)