mktextfm trying to generate a nonsense font

Robert w.m.l at
Sun Mar 15 02:57:36 CET 2020

I stumbled upon a somewhat arcane bug concerning font expansion that 
will probably never show up in the wild (and has existed at least since 
2008), but nevertheless, here we go:

In pdftex, if a font is expanded non-automatically, and pre-generated 
expanded font instances don't exist, mktextfm will kick in, trying to 
generate these fonts on the fly (eg. cmr10+10, where the "+10" denotes 
the desired expansion), but will fail to do so. This is expected.

However, with the following test file (which assumes that expanded 
instances of Charter exist), pdftex will fail in a peculiar manner:

\pdfmapline{+bchr8r CharterBT-Roman " TeXBase1Encoding ReEncodeFont " 
<8r.enc <bchr8a.pfb}
\pdfmapline{+bchr8r+20 CharterBT-Roman " 1.020 ExtendFont 
TeXBase1Encoding ReEncodeFont " <8r.enc <bchr8a.pfb}
\pdfmapline{+bchr8r-20 CharterBT-Roman " 0.980 ExtendFont 
TeXBase1Encoding ReEncodeFont " <8r.enc <bchr8a.pfb}
\pdffontexpand\1 100 100 5 %autoexpand
\pdffontexpand\2 20  20 20
\1 ABC

\2 This is a paragraph with font expansion.

Here, mktextfm will not only try to create the cmr10 instances, but will 
also try to create the fonts "bchr8r-20-100" and "bchr8r+20-100". This 
doesn't make any sense, firstly because both bchr8r-20 and bchr8r+20 
exists, and secondly, because there are two expansion suffixes, the 
"-100" being taken from the cmr10 expansion line.

All will go well, if I append "autoexpand" to the first \pdffontexpand 

Also, this only happens with virtual fonts; that is, if I request bchr8r 
(tfm) instead of bchr8t (vf), mktextfm only kicks in for the cmr10 font 
(as expected), but not for the bchr8r font (also expected).

I could provide the expanded font instances to anybody who might feel 
responsible (and who would consider this being worth the effort). I 
don't even know whether this would be an issue with pdftex or with 


More information about the tex-live mailing list.