[Fontinst] Map files fragment

[Lars Hellström]

At 16.49 +0100 2003-12-12, Paul Pichaureau wrote:
>  I have used recently this new feature of fontinst (creation of map
>file), I found it very useful. This is some comments about it:
>
>* I have created compressed version of the cmtt font. The resulting
>map file looks like:
>
>xcmtt950 CMTT10 <cmtt10.pfb " 0.95 ExtendFont "
>xcmtt900 CMTT10 <cmtt10.pfb " 0.9 ExtendFont "
>xcmtt850 CMTT10 <cmtt10.pfb " 0.85 ExtendFont "
>xcmtt800 CMTT10 <cmtt10.pfb " 0.8 ExtendFont "
>xcmtt750 CMTT10 <cmtt10.pfb " 0.75 ExtendFont "
>xcmtt700 CMTT10 <cmtt10.pfb " 0.7 ExtendFont "
>
>but when tex created this file, it complains:
>
>Map fragments writer warning:
>        Font cmtt10 generated again on input line 15.
>
>
>Map fragments writer warning:
>        Font cmtt10 generated again on input line 17.
[snip]
>I found that quite strange. In fact, the cmtt10 font is not generated
>at all. It is loaded many times, but not generated. Am I missing
>something ?

Well, "generated" is perhaps not the best choice of word; "defined" might
be better. Probably you did something like the following in the main
fontinst command file:

\transformfont{xcmtt950}{\xscalefont{950}{\frompl{cmtt10}}}
\transformfont{xcmtt900}{\xscalefont{900}{\frompl{cmtt10}}}
\transformfont{xcmtt850}{\xscalefont{850}{\frompl{cmtt10}}}

and technically this regererates cmtt10.mtx once for each xcmtt*.mtx you
make. The map file fragments writer worries that these files are not
necessarily identical and thus warns you that there may be inconsistencies.
The line numbers should point you to the \storemapdata commands which
specify the origins of the cmtt10 font although that has already been
defined.

The test could however be refined. In particular it would be reasonable to
check whether the new and old definitions are identical and in that case
don't emit this warning.

>* the default prefix of outline file is *.pfa. As far as I know, *.pfb
>is much more frequent.

The traditional set-up has been that .pfa is dominant on Unix platforms,
.pfb on Windows, and LWFNs on Macs. (I have the impression that drivers
with PDF as target tend to leave out PFA support (probably because it is
slightly trickier to interpret), and that might have given PFB a more
dominant role, but it is hard to say for sure.) Hence there are historical
reasons for this.

>* I think the concept of driver (in the sense it is used here) will
>become obsolete with the updmap utility. On my system (miktex 2.3 /
>windows xp) the same map file is used to configure all the driver (I
>use commonly dvips, yap, pdftex). Perhaps a generic driver 'updmap'
>could be useful. By the way, the map file generated with the actual
>dvips driver fits well with the updmap utility.

Yes, udpmap as an alias for the current dvips might well be useful.

Lars Hellström