Bug 2229010

Summary: Font packaging issue with newpxtext in texlive breaks pdflatex if footnotes used
Product: [Fedora] Fedora Reporter: Karl <kaiserkarl31>
Component: texliveAssignee: Tom "spot" Callaway <spotrh>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 38CC: caznaranl, spotrh, than
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Karl 2023-08-03 21:58:20 UTC
Using the newpxtext package (Palatino typeface) along with \footnote causes PDFTeX to crash without producing a PDF due to a missing font file. The problem is not universal: one Fedora 38 installation I have works fine, two others do not. The following file reproduces the issue if it exists on the machine in question:

\documentclass{article}
\usepackage{newpxtext}
\begin{document}
Hello, world!\footnote{this is a footnote}
\end{document}

Omitting the footnote avoids the problem.

Reproducible: Sometimes

Steps to Reproduce:
I am not 100% certain these steps will work; it's my working hypothesis.

1. Upgrade from Fedora 36 directly to Fedora 38
2. Create the file above in a text editor (call it "test.tex", say)
3. run "pdflatex test.tex"
Actual Results:  
Many pdftex warning messages, then 

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


Expected Results:  
I think the problem is that it's looking for npxsups_t1.enc and the file is npxsups_T1.enc

I cannot easily test my hypothesis, but I confirmed that a Fedora 36 -> 38 upgrade for a user who has never used pdftex before that it did happen to him (i.e., it's not something in my local configuration).

I can avoid the problem entirely by using "xelatex" instead of "pdflatex" to compile the document.

Comment 1 Karl 2023-08-08 19:55:43 UTC
The "upgrade from Fedora 36 to Fedora 38" step above is not necessary, and in fact the systems that exhibit this bug went from 37 to 38.

Comment 2 Karl 2023-08-08 23:04:48 UTC
I think I figured it out: the key was that I was upgrading from a system that had old, obsolete RPMs from Fedora 34. Specifically,

texlive-updmap-map-svn56618-39.fc34.noarch

was still installed, and I think removing that fixed the problem. I also removed texlive-texlive-docindex-svn54903-39.fc34.noarch and texlive-obsolete-2020-35.fc33.noarch, but I think it's the updmap one that fixed the problem.

I also did a "dnf reinstall texlive-newpx" but I suspect that was probably equivalent to doing a texhash command to rebuild the ls-R database.

Comment 3 Karl 2023-08-08 23:21:44 UTC
I may have inadvertantly blamed the fc34 RPMs above; if I simply do "rm -rf /var/lib/texmf/fonts/map/pdftex/updmap" followed by "dnf reinstall texlive-newpx", it seems to solve the problem.

It does still give me messages like
"pdfTeX warning: pdflatex (file /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map): fontmap entry for `rtxptmri' already exists, duplicates ignored"