Description of problem: Tex documents containing capital latin symbols in "blackboard bold" (eg. \mathbb{R}) will fail to compile with pdflatex. Version-Release number of selected component (if applicable): Fedora 35, texlive-2021-45.fc35 How reproducible: Fully reproducible Steps to Reproduce: 1. Install texlive-scheme-full (so that missing packages can't be the issue) 2. Write a syntactically valid tex document containing blackboard bold character, save it as eg. testfile.tex . The bug is reproducible with eg. the following document: \documentclass[10pt,a4paper]{article} \usepackage[utf8]{inputenc} \usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \begin{document} This is a document! Here is a math symbol, let $\mathbb{Z}$ denote the ring of integers. \end{document} 3. Run pdflatex testfile.tex Actual results: Compilation will fail with error message !pdfTeX error: pdflatex (file msbm10.t3): cannot open Type 1 font file for read ing ==> Fatal error occurred, no output PDF file produced! Expected results: Document should compile into a readable pdf. Additional info: Texlive has been installed with texlive-scheme-full, therefore no packages should be missing. Also, these math symbols compiled fine on Fedora 34 with a texlive-scheme-full installation and *I think* also during the F35 beta (but I don't recall it with certainty if I used tex during the beta). Searching for the file in the error message suggests that the package texlive-mpfonts package is complicit. I have tried to dnf reinstall texlive-mpfonts to see if maybe the installation has been corrupted, but it does not fix the issue.
I've stumbled upon this issue as well and done some more digging, it seems like kpsewhere (which is apparently the utility used to search files) is not properly picking up on msbm10.t3. Now I don't have any clue as to why this is but I have a suspicion which is that when digging through the spec file of the texlive package there is exactly a single type3 font (msbm10.t3) that is packaged so maybe there is some special handling the other fonts are receiving to get properly picked up by kpsewhere and it was simply forgotten for type3 fonts since there is only a single one. However that's just a wild guess and I'm far from experienced enough with texlive to figure out what exactly is wrong here.
Can confirm this bug on my Fedora 35 installation as well.
Some updates: - After a clean install, the issue got worse and I was unable to compile any document that contained any "math mode" (eg. $<anything here>$ or \begin{equation}<anything here>\end{equation}). - A workaround that I can confirm to be working for me can be found in this TeX Stack Exchange question: https://tex.stackexchange.com/q/621447/184053 . In short, running "sudo updmap-sys" fixes the problem. Apparantly this is something the installation script should run but for some reason does not.
The "sudo updmap-sys" fixed the issue for me 10 days ago, but today I cannot compile any document which has fonts from the amssymb package. Here is a minimal "working" file \documentclass{article} \usepackage{amssymb} \begin{document} $\therefore$ \end{document} The command "\therefore" can be replaced by any other symbolname contained in amssymb, like "\boxminus".
I have the same problem since upgrading to fedora 35, but only on one machine out of two that I upgraded nearly at the same time. I don't know what the difference between the two setups could be. Anyway, I did not have any luck with 'sudo updmap-sys', but 'updmap-user' did work for me. That's a temporary workaround only, since it warns that changes in the system won't be reflected and you'd have to re-run 'updmap-user' after each (tex) update. But for now, it works.
(In reply to hpd-redhat from comment #5) > I have the same problem since upgrading to fedora 35, but only on one > machine out of two that I upgraded nearly at the same time. I don't know > what the difference between the two setups could be. > > Anyway, I did not have any luck with 'sudo updmap-sys', but 'updmap-user' > did work for me. That's a temporary workaround only, since it warns that > changes in the system won't be reflected and you'd have to re-run > 'updmap-user' after each (tex) update. But for now, it works. 'updmap-user' doesn't work for me.
I wonder why this bug is not of high priority and severe. The latex system is unusable as a result. At tex.stackexchange.com, there was a suggestion by Ulrike Fischer about the source of the bug and a workaround that worked on all my systems. Namely one should put the line \pdfmapfile{-mpfonts.map} in (every) latex document. I put it into the preamble. https://tex.stackexchange.com/questions/621447/unable-to-generate-a-pdf-on-fedora-35-pdftex-error-cannot-open-type-1-font-fi/621465?noredirect=1#comment1556903_621465 I remark that on Fedora system which was updated from 34 to 35 just a few days ago, the bug is not present. But the fix hasn't made it into the texlive update.
Apologies for the lack of response. This time of year is especially busy for me, as I had to run the open source track at AWS re:Invent. One of the big challenges here is that this, like many of the TeXLive issues in Fedora 35, is not reliably reproducible. Some folks go to Fedora 35 and everything still works, others clearly have a different experience. Narrowing down this issue to the inclusion of mpfonts.map in the pdf fonts mapping is helpful. It very clearly should not be included in the updmap runs. I've already fixed this for psnfss.map (by renaming it to psnfss.oldmap), I'll apply the same fix for mpfonts.map and hopefully this will resolve the issue.
This is good news. So there are people who upgraded from 34 to 35 more than 10 days ago and the minimal example I gave above compiles? I take care of 8 Fedora boxes, and only on one of them I can compile that short file with "$\therefore$" in it; I upgraded this box to 35 a week ago. On all boxes, I have installed the full texlive scheme.
FEDORA-2021-1038a6ffa3 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1038a6ffa3
FEDORA-2021-1038a6ffa3 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-1038a6ffa3` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1038a6ffa3 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Please apply the updates here and let me know if things start to work. I was able to reproduce this issue and this fix resolved it for me (once the new trigger scriptlet runs, it results in a working configuration).
Need more time to thoroughly test, but so far the proposed updates seem to work.
FEDORA-2021-1038a6ffa3 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Please tell me, do I understand correctly that to display math symbols correctly, I need to update the version? I'm so overloaded with algebra right now, there's too much stuff. I started to figure it out through homework assistance from https://essays.edubirdie.com/algebra-help to relieve myself a little. And now there are problems with symbols that also need to be solved urgently because the deadline for submitting my pdfs is approaching.