[OS X TeX] xelatex fontmap error

[Peter Dyballa]

Am 27.05.2010 um 22:53 schrieb cfrees at imapmail.org:

> So how can I figure out where the problematic lines are coming from?


/usr/local/texlive/2009/texmf-dist/fonts/map/dvips/avantgar/uag.map is  
the standard MAP file fragment for the AvantGarde clone font. If it's  
as clean as you cite, then it could come from some private or local  
MAP file fragment (I have half a dozen of them, one for the fonts of  
my PostScript 3 printer). XeTeX's xdvipdfmx uses the pdftex.map MAP  
file. With TeX Live 2009 a first default variant is installed and  
sometimes updated: /usr/local/texlive/2009/texmf/fonts/map/pdftex/ 
updmap/pdftex.map. The system's working copy is a symbolic link: /usr/ 
local/texlive/2009/texmf-var/fonts/map/pdftex/updmap/pdftex.map (you  
can use it like the file itself). One command you could try is:

	wc -l /usr/local/texlive/2009/texmf/fonts/map/pdftex/updmap/ 
pdftex.map /usr/local/texlive/2009/texmf-var/fonts/map/pdftex/updmap/ 
pdftex.map

It will tell the number of lines the files have. Then you could modify  
the command like this:

	grep uagd8a /usr/local/texlive/2009/texmf/fonts/map/pdftex/updmap/ 
pdftex.map /usr/local/texlive/2009/texmf-var/fonts/map/pdftex/updmap/ 
pdftex.map

This will tell you the uagd8a font mappings used in both MAP files. It  
will not reveal from where the faulty line comes. For this you would  
need to iterate over all enabled MAP file fragments. This command  
could perform the search:

	find /usr/local/texlive/2009/texmf-dist/fonts/map -type f -name  
"*.map" -exec grep uagd8a {} /dev/null \;

I presume that no culprit will be found. Probably the updmap-sys  
script had introduced the fault. This could be checked by running:

	sudo /usr/local/texlive/2009/bin/universal-darwin/updmap-sys -- 
disable uag.map
	sudo sh -x /usr/local/texlive/2009/bin/universal-darwin/updmap-sys -- 
enable Map=uag.map

The latter command will (hopefully) show in detail how the shell  
scripts performs it's job. You will see a lot of similar blocks of  
commands or statements when all the MAP fragments are processed.  
Somewhere there the error happened. Or later, when the first created  
output files are prepared for actual use and modified for other  
convertors. It's very likely that the same error will *not* happen  
again. When you now, after updmap-sys has finished, invoke again the  
first two command, starting with 'wc -l' resp. 'grep uagd8a', you  
should see very similar results and no faulty line. If you'll still  
see that faulty line, then we'll really have a problem that can't be  
solved that easily. It would need examination of all your local and  
private MAP file fragments. For example by sending me privately an  
archive of all these files... (which I would check in nine or ten hours)

--
Greetings

   Pete

The most exciting phrase to hear in science, the one that heralds new  
discoveries, is not "Eureka!" (I found it!) but "That's funny..."
				– Isaac Asimov