The latest newtxtext package (v1.601 Oct 2, 2019) seems to have broken the \footnote command.

Here's a MWE

\usepackage{newtxtext}  % <------ comment this line to get a successful compilation


Testing Footnotes\footnote{This is a test for the footnote command}.


When compiled with pdflatex, I get the following error message

!pdfTeX error: pdflatex (file ntxsups_T1.enc): cannot open encoding file for re ading ==> Fatal error occurred, no output PDF file produced!

This file is located at /usr/local/texlive/2019/texmf-dist/fonts/enc/dvips/newtx/ntxsups_t1.enc (the suspicious part being that it is located under the dvips folder).

How can I workaround this issue?

Update 1

The author/maintainer of newtx has acknowledged this issue and have said that they shall be issuing a fix soon.

Update 2

The package author/maintainer has confirmed that a version with a fix for this issue has just been uploaded to CTAN. I wish to thank them for their prompt response on this.

Thanks to the helpful members here who provided workarounds in this matter.

2 Answers 2


It is quite normal that the enc file is located in the dvips sub-tree. The problem here is that the map file requests ntxsups_T1.enc but the actual file is called ntxsups_t1.enc. This is no problem on case-insensitive file systems. As a work-around I would try (untested):

$ mkdir -p ~/texmf/fonts/enc/dvips/newtx
$ cp /usr/local/texlive/2019/texmf-dist/fonts/enc/dvips/newtx/ntxsups_t1.enc \
  • thank you for your answer. That works! Can you please elaborate on case-insensitive filesystems? I am on GNU/Linux. But does that mean that the package update broke all existing documents on Linux for all users worldwide? Oct 9, 2019 at 11:56
  • @Krishna Windows and I believe MacOS use case-insensitive file systems. Yes, I believe this update broke all footnote using documents on Linux systems. Somebody should report it to the package author. Oct 9, 2019 at 12:00
  • 1
    thank you. I have emailed the package author about this. Oct 9, 2019 at 12:06
  • The problem is in the file newtx.map that TeX Live uses for rebuilding pdftex.map; the fix should be done on that file, rather than copying files. For instance, your fix would not work on macOS, which is case sensitive, but doesn't allow two files differing only by letter casing in the same directory.
    – egreg
    Oct 9, 2019 at 14:53
  • 1
    OK, they're not in the same place; but one should remember to remove them when the package is updated.
    – egreg
    Oct 9, 2019 at 15:03

The newtx distribution provides the file newtx.map for rebuilding the main map files (mainly pdftex.map). In this file we read

ntxsups-Regular-ot1 ntxsups-Regular " ntxsupsOT1Encoding ReEncodeFont " <[ntxsups_OT1.enc <ntxsups-Regular.pfb
ntxsups-Regular-t1 ntxsups-Regular " ntxsupsT1Encoding ReEncodeFont " <[ntxsups_T1.enc <ntxsups-Regular.pfb
ntxsups-Regular-ly1 ntxsups-Regular " ntxsupsLY1Encoding ReEncodeFont " <[ntxsups_LY1.enc <ntxsups-Regular.pfb
ntxsups-Italic-ot1 ntxsups-Italic " ntxsupsOT1Encoding ReEncodeFont " <[ntxsups_OT1.enc <ntxsups-Italic.pfb
ntxsups-Italic-t1 ntxsups-Italic " ntxsupsT1Encoding ReEncodeFont " <[ntxsups_T1.enc <ntxsups-Italic.pfb
ntxsups-Italic-ly1 ntxsups-Italic " ntxsupsLY1Encoding ReEncodeFont " <[ntxsups_LY1.enc <ntxsups-Italic.pfb
ntxsups-Bold-ot1 ntxsups-Bold " ntxsupsOT1Encoding ReEncodeFont " <[ntxsups_OT1.enc <ntxsups-Bold.pfb
ntxsups-Bold-t1 ntxsups-Bold " ntxsupsT1Encoding ReEncodeFont " <[ntxsups_T1.enc <ntxsups-Bold.pfb
ntxsups-Bold-ly1 ntxsups-Bold " ntxsupsLY1Encoding ReEncodeFont " <[ntxsups_LY1.enc <ntxsups-Bold.pfb
ntxsups-BoldItalic-ot1 ntxsups-BoldItalic " ntxsupsOT1Encoding ReEncodeFont " <[ntxsups_OT1.enc <ntxsups-BoldItalic.pfb
ntxsups-BoldItalic-t1 ntxsups-BoldItalic " ntxsupsT1Encoding ReEncodeFont " <[ntxsups_T1.enc <ntxsups-BoldItalic.pfb
ntxsups-BoldItalic-ly1 ntxsups-BoldItalic " ntxsupsLY1Encoding ReEncodeFont " <ntxsups_LY1.enc <ntxsups-BoldItalic.pfb

but the corresponding files are named


The newtx.map file should be fixed to contain the correct names. The problem doesn't show up on Windows systems, that are case insensitive.

With suitable privileges open


Fix the faulty entries shown above changing the file names to match the distributed ones, save and, again with suitable privileges, run

updmap -sys

Once the package is updated, the fix will disappear, whatever method the package maintainer will choose to use in order to correct the faulty behavior.

The fix has been tested.

  • thank you. The maintainer has acknowledged this issue and said that they shall be issuing a fix soon. Oct 9, 2019 at 17:48

You must log in to answer this question.

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