having fontinst write font map file

[Lars Hellström]

Hello, all.

I've spend some time the last week pondering the idea of having fontinst
writing a font map file. I came up with the following suggestion.

Say we add two new commands \recordtransforms and \endrecordtransforms to
fontinst. The suggested effect of these commands is that every
\transformfont that takes place between them should not only carry out the
transformation of font metrics as it does now, it should also make a record
of the transform in an auxiliary file (the name of which is specified in an
argument to \recordtransform). This record should be in such a format that
it later can be made to act as a command with the effect to make TeX
actually write out an entry to the map file that is generated.

The primarly reason for my suggesting writing this information to an
auxiliary file like this is that I think it should be possible to separate
generation of VPL files and generation of map file(s) on two different TeX
runs. The advantage with that is lower memory requirements and it should be
a simple matter to add this extra step to descriptions of how to run
fontinst. (Besides, some people might not want to make a map file, perhaps
because they already have it, and then there is no need to spend time
making it.)

I imagine that a record of a font transformation should be something like

  \makemapentry{TFM-NAME}{SOURCE}{TRANSFORMS}

where the TFM-NAME is the same thing as the first argument of
\transformfont ---
the name of the TeX-font for which an entry should be made. SOURCE should
contain all the information about the source for the font metrics that can
be relevant, thus in particular the name of the source metric file and
whether it was an AFM, PL, or MTX. An interesting point here is that since
an AFM file contains the PS-name of the font (it does, right?), we could
include that piece of information as well; it ought to be rather useful. I
would suggest that SOURCE can be one of the three following things:

  \fromafm{AFM-NAME}{PS-NAME}
  \frompl{PL-NAME}
  \frommtx{MTX-NAME}

The TRANSFORMS argument should contain the font transformations that have
been made on the font. (BTW, since noone seem to have had any objections to
the matrix model I wrote about a while back, I have implemented it. It
means the font transforms work a bit differently to how they used to, but
only more like one would expect.)

One thing about the above that must be observed is that even in the case
that one is only to generate a map file for dvips, there will not be
sufficient information in the above \makemapentry, since there is always
the matter of whether, and if so how (partially or not partially) each
specific font should be downloaded to the printer. There is certainly
enough information to make an educated guess, but one would like to have
the ability to tell fontinst to do this or do that at least for each
PS-font individually. I also expect that there are lots of people (I'm one)
who do not have their PS-font files named according to the Berry scheme
since they use them for something non-TeX as well. For such people it
should be possible to specify in advance that for example the name of the
file to download for the font whose metrics were in padr8a (.afm) is
AGarReg and other things like that. There should be room for a lot of
configuration.

In fact, I think the need for configurability (hmm, is that a word?) is so
great that we need to be very careful when constructing the part that is
actually going to generate the map files. It's no fun discovering in six
months from now that some little piece of information which we thought
there was no need to configure actually must be subject to some
configuration, and then having to start all over again.

What I suggest we all on this list spend some time on during the next month
or so is to check how the various map, driver configuration, etc. files,
that one could want \makemapentry to write entries to, look. What is
primarily of interest is what information is needed to make an entry, and
secondly from what other information each specific item can be computed.
Given that, I think the team will have a pretty good idea about which data
structures would need to be constructed to support generation of map files.

I do not however expect that the team will be willing to spend
particularily much time actually writing the routines for generating a
large variety of map files. Files for the drivers we use ourselves, quite
probably, but not to any larger extent for other drivers. There I would
rather expect that we will rely on the fontinst community at large to make
contributions. If we do a good job constructing the underlying data
structures, including support for one more driver will probably not be that
hard, so you should not have to be such a great TeXnician to write the
routines needed.


Finally, a small example of one kind of map file and the information needed
for it, namely the font part of an OzTeX config file (between
begin_fonts/add_fonts and end_fonts):

The basic format is that one line corresponds to one entry. This line
consists of some number of words that are separated whitespace. (I suppose
this is a rather common format.)

The first word on a line is the TFM name of a font; this is immediately
available in the above \makemapentry. The second word is ignored, but it
used to be the PS-name of the font, so in case this is known, the PS-name
should be put here. The third word is the MacOS Font Manager's name for
this font, i.e., the name of the Mac font that will be used when viewing a
DVI or printing to a non-postscript printer; this cannot be deduced from
the information supplied to  \makemapentry, the user must provide it. The
fourth word is the name of a "encoding file" that will be used to translate
TFM character codes to character codes for the MacOS font (or the word
"nil" if no reencoding is required); this cannot be deduced either, but
educated guessing will work most of the time. The fifth word is the style
of the MacOS font that will be used; the contents here cannot be deduced
any more than those of the third word.

Clearly, making OzTeX config files requires that quite a lot of extra
information is provided in some way, probably by the user preparing some
file with configurations linking source font, Mac font name, and ditto
style for all the fonts involved. I would expect similar cases arise for
other drivers.

Lars Hellström