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.
-
To see what an image I consists of, run Imageto with the
`-strips' option. This produces a bitmap font `Isp' in
which each character is simply a constant number of scanlines from the
image.
-
Run Fontconvert (see section 8. Fontconvert) on `Isp' with the
`-tfm' option, to produce a TFM file. This is because of
the next step:
-
Run TeX on `imageto/strips.tex', telling TeX to use the
font `Isp'. This produces a DVI file which you can print or
preview as you usually do with TeX documents. (If you don't know how
to do this, you'll have to ask someone knowledgeable at your site, or
otherwise investigate.) This will (finally) show you what is in the
image.
An alternative to the above steps is to run Imageto with the
`-epsf' option. This outputs an Encapsulated PostScript file with
the image given as a simple PostScript bitmap. Then you can use
Ghostscript or some other PostScript interpreter to look at the EPS file.
This method is simpler, but has the disadvantage of using much more
disk space, and needing a PostScript interpreter.
-
If the original was not scanned in the normal orientation, the image
must be rotated 90 degrees in some direction and/or flipped end for end.
(Sometimes we have not scanned in the normal orientation because the
physical construction of the book we were scanning made it difficult or
impossible.) In this case, you must rotate the image to be upright.
The program IMGrotate does this, given the `-flip' or
`rotate-clockwise' option. Given an image RI, this outputs
the upright image I.
-
Once you have an upright image I, you can use Imageto
(see section 6. Imageto) to extract the characters from the image and make a
bitmap font `I.dpigf', where dpi is the
resolution of the image in pixels per inch. (If the image itself does
not contain the resolution, you must specify it on the command line with
`-dpi'.) To do this, you must first prepare an IFI file describing
the image. See section 6.2 IFI files, for a description of IFI files.
-
To view the resulting GF file, run Fontconvert to make a TFM file, as
above. Then run TeX on `testfont.tex' and use the
\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.
-
Once all the characters have been properly extracted from the image, you
have a bitmap font. Unlike the above, the following steps all interact
with each other, in the sense that fixing problems found at one stage may
imply changes in an earlier stage. As a result, you must expect to
iterate them several (billion) times.
At any rate, given a bitmap font f you then run Charspace
(see section 9. Charspace) to add side bearings to f, producing a new
bitmap font, say g, and a corresponding TFM file
`g.tfm'. To do this, you must prepare a CMI file specifying
the side bearings. See section 9.2 CMI files, for a description of CMI files.
-
To fit outlines to the characters in a bitmap font, run Limn
(see section 10. Limn). Given the bitmap font g, it produces the BZR
(see section 11.6 BZR files) outline font `g.bzr'. The side bearings
in g are carried along.
Although Limn will (should) always be able to fit some sort of outline
to the bitmaps, you can get the best results only by fiddling with the
(unfortunately numerous) parameters. See section 10.2 Invoking Limn.
-
To convert from the BZR file `g.bzr' that Limn outputs to a
font format that a typesetting program can use, run BZRto
(see section 11. BZRto). While developing a font, we typically convert it to a
Metafont program (with the `-metafont' option).
As you get closer to a finished font, you may want to prepare a CCC file
(see section 11.4 CCC files) to tell BZRto how construct composite characters
(pre-accented `A's, for example) to complete the font.
-
Given the font in Metafont form, you can then either make
the font at its true size for some device, or make an enlarged version
to examine the characters closely. See section 11.1 Metafont and BZRto, for the
full details.
Briefly, to do the former, run Metafont with a 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.
-
Problems can arise at any stage. For example, the character spacing
might look wrong; in that case, you should fix the CMI files and rerun
Charspace (and all subsequent programs, naturally). Or the outlines
might not match the bitmaps very well; then you can change the
parameters to Limn, or use XBfe (see section 13. XBfe) to hand-edit the bitmaps
so Limn will do a better job. (To eliminate some of tedium of fixing
digitization problems in the scanned image, you might want to use the
filtering options in Fontconvert before hand-editing; see 8.1.3 Character manipulation options.)
Inevitably, as one problem gets fixed you notice new ones ...