Re: AFM files

[Reimer Behrends]

On Fri, Jul 20, 2001 at 11:53:52AM +0400, Paul K. Efremov wrote:
[...]
> There is also printafm.ps shipped with Ghostscript, but it only works
> with Ghostscript itself (uses non-standard operators). This can be 
> used if you have Type1 files on disk, but don't have AFMs with them.
> 
> Of course both of them do not preserve kerning pairs, as noted in BUGS
> section of getafm manual.

It should at this point perhaps be noted that pf2afm, which also comes
with Ghostscript and _does_ generate kerning pairs if you supply a PFM
file, had better be used with care. While it tries to extract kerning
pairs from the PFM file, it will totally mess up the kerning pairs if
the encoding vector [1] inside the PFB/PFA file does not correspond to
the one used to create the PFM files.

One big reason here is that PFM is a braindead format: kerning pairs are
given as pairs of bytes (denoting character codes) followed by a short
integer (denoting kerning adjustment). As such, only characters _inside_
the encoding can be kerned, but not any additional characters. To add
insult to injury, the encoding used for the PFM file (and specified by a
single byte with apparently not so clear semantics) is often only
tangentially related to the one inside the PFB file (which pf2afm uses
to interpret the two bytes of the kerning pairs). This frequently
results in kerning pairs outside the ASCII range to be little more than
random noise, and any characters outside the encoding never being kerned
at all (good luck if you have a font with both Latin1 and Latin2
characters).

Luckily, you can usually tell by pf2afm protesting that there were
.notdefs generated (a result of it finding character codes from kerning
pairs that didn't map to glyphs). Unfortunately, even professional tools
seem to suffer from that problem; only recently I had to fix a few
thousand AFM files supposedly generated by Fontographer which exhibited
the same problem, and where it was essentially necessary to splice in
the kerning information from the corresponding TrueType files.

                        Reimer Behrends

[1] The encoding vector maps character codes ranging between 0 and
    255 to the names of individual glyphs, such as /hyphen or /OE.