I had the same problem with texlive 2020 and did a full installation of texlive 2021:

\font\tenrm=mdugmm7y at 10pt 
Hello World!

doesn't work with tex, pdftex, xetex or luatex. All of them complain that they cant access the font. And this happens for almost every font. Even when I put mdugmm7y.tfm and mdugmm7y.vf in the same directory it doesn't work. The error from xetex is:

xdvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...

Tex creates a dvi but there a just random symbols and no actual text.

Using truetype or openttype fonts with fontspec in latex works fine. I only have these problems with the tfm fonts.

  • Sorry, but I can't replicate your issue.
    – egreg
    May 15, 2021 at 20:22
  • @egreg Mmh, thats weird, I did a full reinstallation of tex live 2021 to make sure that this issue wasn't caused by the texlive version my distribution ships (slackware). There were also no issues during the installation... So which texlive version do you use?
    – M0M0
    May 16, 2021 at 17:20
  • On Linux boxes I always install the Tug TeX Live tug.org/texlive
    – egreg
    May 16, 2021 at 19:35
  • I'm using the same tex distribution. I have the same problem on mint and when installing it via guix. So did you run your test on Linux as well? If so please tell me which distribution you were using.
    – M0M0
    May 17, 2021 at 0:03
  • type -a xdvipdfmx xdvipdfmx is /usr/local/texlive/2021/bin/x86_64-linux/xdvipdfmx xdvipdfmx is /usr/local/texlive/2021/bin/x86_64-linux/xdvipdfmx xdvipdfmx is /usr/bin/xdvipdfmx
    – M0M0
    Jul 23, 2021 at 19:47

2 Answers 2


Note that you can often get better error messages for font related issues from xetex by running xdvipdfmx by hand (after xetex --no-pdf) as unfortunately the automatic call to xdvipdfmx suppresses error messages.

You get no error from xetex as the tfm file for the font is in texlive

$ xetex --no-pdf aa803
This is XeTeX, Version 3.141592653-2.6-0.999993 (TeX Live 2021) (preloaded format=xetex)
 restricted \write18 enabled.
entering extended mode
(./aa803.tex [1] )
Output written on aa803.xdv (1 page, 248 bytes).
Transcript written on aa803.log.

But runing the dvi driver you get

$ xdvipdfmx aa803.xdv
aa803.xdv -> aa803.pdf
kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 ugmm8a
mktexpk: don't know how to create bitmap font for ugmm8a.
mktexpk: perhaps ugmm8a is missing from the map file.
kpathsea: Appending font creation commands to missfont.log.

xdvipdfmx:warning: Could not locate a virtual/physical font for TFM "md-gmm8y".
xdvipdfmx:warning: >> This font is mapped to a physical font "ugmm8a".
xdvipdfmx:warning: >> Please check if kpathsea library can find this font: ugmm8a
xdvipdfmx:fatal: Cannot proceed without .vf or "physical" font for PDF output...

No output PDF file written.

as the tfm file is referencing a virtual font but the actual font (corresponding to URW Garamond) is not in texlive by default.

You can install the missing files with getnonfreefonts as documented here


Note that using 8-bit legacy fonts with xetex is not recommended, no hyphenation patterns for these encodings are loaded into the default format. This doesn't make much difference if you are writing English with no accented letters but becomes important in many languages.

  • xetex -output-driver="xdvipdfmx -vv" avoids the double call.
    – egreg
    Aug 10, 2021 at 9:00
  • @egreg yes I know but somehow it seems more complicated to pass in the driver options nested as an option to xetex and in fact I never do it that way: I always revert to my roots and do it in two steps if I need to see what xdvipdfmx is doing. Aug 10, 2021 at 9:02
  • The 7y part means that the font is suitable for an OMS encoded font, so there is no hyphenation problem.
    – egreg
    Aug 10, 2021 at 9:24
  • @egreg yes (although it's being used for text here) but the real document may have more than one font loaded so this seemed worth mentioning. Aug 10, 2021 at 9:32

The mystery can be explained. If I do

vftovp mdugmm7y

I get

   (FONTNAME md-gmm7y)
   (FONTCHECKSUM O 23602320625)
   (FONTAT R 1.0)
   (FONTDSIZE R 9.962616)
   (FONTNAME md-gmm8y)
   (FONTCHECKSUM O 32734444133)
   (FONTAT R 1.0)
   (FONTDSIZE R 10.0)
   (CHARWD R 0.498)
   (CHARHT R 0.707)
   (CHARDP R 0.238)
      (SELECTFONT D 1)
      (SETCHAR O 247)
   (CHARWD R 0.498)
   (CHARHT R 0.6875)
   (CHARDP R 0.238)
      (SELECTFONT D 1)
      (SETCHAR O 206)
   (CHARWD R 0.498)
   (CHARHT R 0.707)
   (CHARDP R 0.183)
      (SELECTFONT D 1)
      (SETCHAR O 207)

The md-gmm8y font is mapped to ugmm8a.pfb both with pdftex and xetex, but the former only loads PFB files that are actually required in the PDF, whereas xdvipdfmx wants to access them as soon as they're referenced. By the way, the characters taken from md-gmm8y are § † ‡ ¶.

Now, lo and behold, ugmm8a.pfb is only available if you install garamond with getnonfreefonts (which I have done in my macOS box). If I try the sample file on a Fedora box with no getnonfreefonts action, then pdftex is happy, unless I also ask for \char'170, when I get

!pdfTeX error: pdftex (file ugmm8a.pfb): cannot open Type1 font file for reading

After installing getnonfreefonts and doing (with superuser privileges)

getnonfreefonts --sys garamond

all goes well.

What's the possible explanation? When mathdesign was being developed, the URW Garamond fonts used to be available in TeX Live; they were later withdrawn for licensing reasons. The involved glyphs are added in the virtual fonts in order to make the font to provide a complete font in the OMS encoding. The difference in behavior between pdftex and xetex about PFB loading has never been noticed before, possibly because nobody tried to use mathdesign Garamond with XeLaTeX.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .