2

What does it mean when pdftex.map has two encoding files in the entry of one font?

Background: I am one of the maintainers of matplotlib, a Python plotting library. One feature of matplotlib is that it can process all text strings through TeX, read the resulting dvi file and embed the results in the plot. When implementing this functionality, I found out that the fonts referenced in dvi files have to be looked up in a map; out of the few map files available in a typical TeX distribution I chose pdftex.map, which is documented in Chapter 5 of the pdftex manual. That manual specifies the following format for each line in this map file:

tfmname basename fontflags special encodingfile fontfile

It says that the special, encodingfile, and fontfile fields can be in any order, and that encodingfile can be left out, but it does not say that there can be more than one encodingfile.

Now some users are reporting that TeX Live 2010 installs a pdftex.map file that has the following line:

pbkdo8y URWBookmanL-DemiBold ".167 SlantFont TeXnANSIEncoding ReEncodeFont" <texnansi.enc <8r.enc <ubkd8a.pfb

Is this a bug in TeX Live, and what does pdftex do with this information? Does it include an embedded PostScript interpreter that reads both encoding files, parses the special field and decides that texnansi.enc contains the encoding that needs to be applied?

Improve this question

2 Answers 2

Reset to default
1

I don't know if the additional enc-file does any harm (I doubt it) but it is certainly senseless and quite probably simply a typo in a map-file. At first 8r.enc would have an effect only if they were a corresponding declaration TeXBase1Encoding ReEncodeFont. And at second a font can't be encoded in two different ways at the same time.

Improve this answer
2
  • With dvips I'm sure the 8r.enc would have an effect only with that declaration, but are you sure about pdftex? I think dvips can simply echo the "special" field in the output PostScript file, and the end-user's PostScript interpreter takes care of the re-encoding, but pdftex has to perform the mapping itself (there is no ReEncodeFont command in pdf; you just output a font). I think the pdftex documentation implies that you don't need any ReEncodeFont commands in the map file, pdftex simply applies any encoding file given.
    – Jouni K. Seppänen
    Feb 12, 2011 at 8:13
  • Yes you are right: The documentation clearly says that pdftex needs only the enc-file. This means that my guess that the aditional enc-files doesn't do any harm is probably wrong: It is quite possible that the second enc-file "wins" and this is clearly (from the ReEncodeFont declaration) not wanted. Perhaps I have some time tomorrow to make some tests.
    – Ulrike Fischer
    Feb 12, 2011 at 11:39
1

Hàn Thế Thành reports that pdftex simply takes the last of the encoding files without regard to the TeXnANSIEncoding ReEncodeFont input. I think this is therefore a bug in TeX Live, since the font should probably be encoded with the other encoding.

Improve this answer

You must log in to answer this question.

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