The issue appears in both GNOME’s Evince and KDE’s Okular. Using the Fonts tab in Evince’s Properties window, I found an entry for a font named “Symbol” for which Evince substitutes Noto Sans Regular.
I tried installing Noto Sans Symbols and Noto Sans Symbols2 from Software and rebooting, but this did not solve the issue–Evince continues use Noto Sans Regular.
Is there a way for the user to rectify this, or should be I looking to file a bug report? Thanks!
IIUC, I would guess that whatever the cause, it is at the source where the pdf was created. A pdf is essentially an image and not a text document that can be affected by the installed fonts at the point where it is being read.
The PDF I’m having trouble with is a copyrighted work, but fortunately the issue persists when I use PDF Mix Tool to extract a single page, which should be okay since it’s clearly not useful on its own. Here it is hosted on Google Drive:
pdffonts is telling me your PDF uses the following fonts, none of which are embedded into it:
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Courier Type 1 Custom no no no 8 0
Times-Italic Type 1 Custom no no no 9 0
Times-Roman Type 1 Custom no no no 10 0
Times-Bold Type 1 Custom no no no 11 0
Symbol Type 1 Custom no no yes 12 0
Do you have them installed on your system?
Please try to post the result of fc-match "Courier" and then of the other 4 fonts
Those are all part of the “standard” 14 fonts that PDF viewers are expected to have. However, since that is hardly portable (given font licensing), currently advice is that all fonts should be embedded. But of course that doesn’t help with existing files.
On F35, the Fonts tab in the Properties window of Evince tells me that it is using:
So this fc-match command is coming from fontconfig? Then I guess the next step is to find out if Evince is using some other mechanism to choose fonts? I’m running version 42.2, I’ll try looking in release notes and maybe commit messages.
* dvi: Remove support for T1 fonts on dvi (Germán Poo-Caamaño)
My copy of the “Standard Symbols PS” font that fc-match seems to like is a T1 font. We’re dealing with a PDF, not a DVI, but I can imagine that a removal of T1 support for one file format might introduce a bug breaking another. I’ll try searching to see if the Evince project already has an issue for this.
As you can see from my F35 system, it never picked a T1 font there either. For fontconfig, I think you’d need to do fc-match "Symbols:fontformat=truetype".
I don’t think evince would use fontconfig directly, but Pango or HarfBuzz. You could try putting S → L&N → N, in a file, and then running pango-view --font=Symbols $filename. If that doesn’t work, it may be something in Pango, if not then evince. Of course, it could still be something font-specific too.
I checked in FontForge, and the symbol for rightwards arrow is glyph 0x2192. I installed google-noto-sans-vf-fonts in an F36 container, and checked that file and it does not contain that glyph. The glyph is in the NotoSansSymbols-Regular.ttf and NotoSansSymbols-VF.ttf, notNotoSans-VF.ttf, unlike DejaVu Sans, which has no separate symbols font file.
So I think you should file a bug, as Noto Sans should not be picked for Symbols, but Noto Sans Symbols should instead.