The font can be easily installed via the script getnonfreefonts
. It is available at tug.org:
TUG getnonfreefonts
EDIT: I tried the installation of getnonfreefonts on my Mac. In the follwoing explaniation I will try to explain my steps.
First I have the following machine:
- iMac 27"
- Installed updated MacTeX 2011
Now the steps.
- I downloaded the installation script.
Open the terminal and go to the folder Download
cd Download
Run the installation:
sudo texlua install-getnonfreefonts
The installation finished and the scipts with their execute files getnonefreefonts
and getnonfreefonts-sys
are now located at
/usr/local/texlive/2011/bin/x86_64-darwin/
Now you can run the script
sudo getnonfreefonts-sys -a
Based on the comments received, I've been able to answer my question.
See page 27 of the current manual for microtype. ! pdfTeX error (font
expansion): auto expansion is only possible with scalable fonts.
Automatic font expansion has been improved in pdfTeX 1.40, in that it
now not only works with Type 1 fonts but also with TrueType, OpenType
and even non- embedded fonts. The above error message indicates either
that you are trying to apply expansion to a bitmap (pk) font, which is
still not possible, or that the font isn’t found at all, e.g., because
of missing map entries. – cfr
And so the Computer Modern default is the culprit, since it couldn't have been expanded by the LaTeX Microtype package. Bookman and Newcent had worked only because they called up both a Roman alternative and a Sans alternative (my novel uses both). The other packages had failed because they only implemented their own Roman font, while using my TeX distributions default, Computer Modern in my case.
The solution is to set the default fonts in all my LaTeX Preamble templates (that I use with this machine) to Latin Modern, which has identical metrics, is designed to appear identical, but has [T1]fontenc encoding capabilities, which my Microtype package will handle. PdfLaTeX should not be crashing, even so, but since it does, this is the fix. For posterity and others that might have the same problem, here's the fix to the Preamble segment from the question:
%%%%%% novel project %%%%%%%%%
\documentclass{book}
\usepackage{microtype}
\usepackage[T1]{fontenc}
%%% % FIX: change to [T1]fontenc microtype expandable fonts % %%%
\renewcommand{\ttdefault}{lmtt} % FIX: default Computer Modern TT
% changed to Latin Modern TT (typewriter)
\renewcommand{\rmdefault}{lmr} % FIX: default Computer Modern Roman
% changed to Latin Modern Roman
\renewcommand{\sfdefault}{lmss} %FIX: default Computer Modern Sans Serif
% changed to Latin Modern Sans Serif
% % % % % % % % % % % % % % % % % % %
% % % % % PSFNSS2e font packages % % % % % % % %
% % % % % select one package % % % % % % %
% \usepackage{mathptmx} % Times font, default sans
% \usepackage{charter} % Bitstream's Charter font, default sans
% \usepackage{mathpazo} % Palatino font, default sans
% \usepackage{bookman} % Bookman font, Avant Garde sans
% \usepackage{utopia} % Utopia font, default sans
% \usepackage{chancery} % Zapf Chancery font, default sans
% \usepackage{newcent} % New Century Schoolbook font, Avant Garde sans
% % % SELECT NONE ABOVE TO USE Latin Modern new defaults % % % %
%%%%%%% END PREAMBLE %%%%%%%%%%%%%%%%
Best Answer
What causes the problems?
The essential problem here is that
updmap
is executed in some way, shape or form.Running an older version of
getnonfreefonts
causes problems because it executesupdmap
.Running
getnonfreefonts --user
causes problems because it executesupdmap
.Other font installation scripts cause this problem because they execute
updmap
. (Of course, not all scripts do this. But our concern here is with those which do.)Finally, of course, executing
updmap
directly causes problems because it executesupdmap
.What is the problem with
getnonfreefonts
[older versions] andgetnonfreefonts --user
?They run
updmap
. (See previous section if you are still unclear on this point.)What is the problem with
updmap
?Short answer
In essence, the problem is that
updmap
creates personal font mapping files which are not updated when fonts are removed, added or updated for the system-wide installation of TeX Live (e.g. whentlmgr
is used to update).Detailed explanation
Tex Live provides a series of commands for managing a TeX installation. An especially important group of commands come in two flavours. These commands are named like this:
<command name>
and/or<command name> --user
<command name>-sys
and/or<command name> --sys
The command we are interested in,
updmap
, is one of these commands. That is, it comes in two flavours:updmap
updmap-sys
This means that the first command manages configuration and installation for the current user only. The second command,
updmap-sys
, manages configuration and installation for all users, system-wide.Both
updmap
andupdmap-sys
read a series of configuration files which tell them which.map
files to look for and which to activate, as well as some information about how fonts should be used. They then try to read these.map
files and use the information from them to create a number of 'super'.map
files for various programmes to use.Suppose, for example, that the programme finds a configuration file with the following lines
This tells it, among other things, to read the file
AnonymousPro.map
and enable the fonts that file describes.For example, the first few lines of this file are
which tells TeX, basically, what to do with requests for various fonts from the AnonymousPro family.
The crucial thing is that
updmap
orupdmap-sys
read this file and add the relevant information to the 'super'.map
files they produce.For example, they would add the following lines to
pdftex.map
, which pdfTeX uses in translating your request for AnonymousPro fonts into reality:When you compile a document using pdfTeX or TeX, the small
.map
file fragment which is part of the package of AnonymousPro fonts is not read: TeX only reads the 'super'.map
files which include information about all of the fonts available to the installation.So far, both
updmap
andupdmap-sys
do the job.But because
updmap
configures things only at the level of the individual user, it creates 'super'.map
files inTEXMFVAR
. On a typical GNU/Linux installation, this is~/.texliveYYYY/texmf-var
whereYYYY
is the edition of TeX Live (e.g.2017
).The immediate results of this are great. The individual user finds everything works and newly installed fonts are suddenly available for use in documents.
But the files in
TEXMFVAR
now supersede the system-wide copies ofpdftex.map
and so on. Right now, that's OK because all of the system-wide information will be replicated in the new versions inTEXMFVAR
.The problems begin when the installation is updated. Let's suppose that the user now runs
tlmgr
to update the installation and is excited to see that a new type1 postscript font, GorgeousGraffiti, is installed.tlmgr
does all the updating of everything, so it should be all ready to use. The user reads the documentation and tries to use the new font in a document.TeX now complains that it cannot find the font. As it isn't sure what to do, it tries to find an
.mf
recipe to create a.pk
file but, of course, there isn't one. Compilation fails.Why?
When the user compiles with pdfTeX, the programme reads the 'super'
.map
files it uses. It gives priority to the ones inTEXMFVAR
- not the system-wide ones. For example, it gives priority to the user's personalpdftex.map
and doesn't read the system-wide one. (Similar things happen if the user uses TeX rather than pdfTeX.)But
tlmgr
manages the system-wide configuration and installation. So it added the information about GorgeousGraffiti not to the individual user's copy ofpdftex.map
but, rather, to the system-wide copy inTEXMFSYSVAR
. In order to get the information about GorgeousGraffiti added to the user's copy ofpdftex.map
, the user needs to runupdmap
again. And the same thing will happen every timetlmgr
makes changes to the system font configuration - to integrate those changes in the user's copy ofpdftex.map
, the user needs to runupdmap
again.This is, to put it mildly, a Pain.
Running
updmap
even once means that the system-wide font map information will never be read again.In contrast,
updmap-sys
deals with the system-wide configuration. When you usegetnonfreefonts --sys
to install additional fonts, for example, the fonts are installed inTEXMFLOCAL
andupdmap-sys
is used to add information about those fonts to the system-wide configuration.When
tlmgr
is used to update the installation in this case, it will add the information about GorgeousGraffiti to the system-widepdftex.map
etc. as before. But this time, when the user compiles a document which uses that font, pdfTeX will not find any copy ofpdftex.map
in the user's personalTEXMFVAR
. So, it will use the system-wide one fromTEXMFSYSVAR
instead. Since this version has been updated with the new information, pdfTeX will know all about GorgeousGraffiti and the document will compile successfully.The moral of the story
Use
getnonfreefonts --sys
to install additional fonts.getnonfreefonts
in the usual way.getnonfreefonts
, with two flavours:getnonfreefonts --user
andgetnonfreefonts --sys
. [Older installations may instead havegetnonfreefonts
for the user case andgetnonfreefonts-sys
in place ofgetnonfreefonts --sys
.getnonfreefonts --sys
should work in this case, too.]getnonfreefonts --sys
.getnonfreefonts --sys
andgetnonfreefonts --user
are the same basic command, the flavour you choose matters. If you call it bygetnonfreefonts --sys
, it will do The Right Thing. If you call it bygetnonfreefonts --user
, it will do The Wrong Thing.If you use another font installation script, make sure it uses
updmap-sys
. Do not use a script which will runupdmap
.If you need to update the map files directly, always use
updmap-sys
.If you read this too late
Start by executing the following command to move the files generated by
updmap
out of the way. This only renames the directory. If all goes well, you can delete it later.Note that running this command may cause slower compilation of some documents initially. For example, cache information will have to be regenerated by LuaTeX,
.pk
fonts will need to be recreated etc. It will be similar to first compilation after installing a new edition of TeX Live.Note that
TEXMFVAR
only contains generated files. So everything here can be regenerated by TeX as required.Now make sure that any fonts and associated files installed in
TEXMFHOME
are removed. If you aren't sure where that is, runkpsewhich --var-value TEXMFHOME
. Do not delete the entire directory! If you have installed custom classes or packages, you want to keep those. You will need to check what should be removed and what not.If you are sure you've not installed custom packages or classes into
TEXMFHOME
, you can tryAgain, you can remove the directory later if you are sure you don't need anything in it.
Note that
TEXMFHOME
contains non-generated files. So if you delete essential stuff here, TeX cannot remake it for you!When you are done, write the moral of the story on a note for yourself so you don't have to go through this again!