Missing characters in PDFs since upgrade from F35 to F36

Since upgrading to a fresh installation of F36 from F35, I’ve discovered that one of my PDF documents now has missing characters:

The missing characters include →and ≥ so far.

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.

1 Like

PDFs are definitely not “essentially an image”, though they might embed some. Fonts may or may not be embedded.

Is this a PDF that could be shared somewhere?

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:

https://drive.google.com/file/d/1RI6_eOxsojzno8Qj_axdyCxbojZVH5G5/view

The screenshot in my original post is taken from the second paragraph near the top of the page.

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:

  • Courier → NimbusMono PS-Regular
  • Times-Italic → NimbusRoman-Italic
  • Times-Roman → NimbusRoman-Regular
  • Times-Bold → NimbusRoman-Bold
  • Symbol → DejaVu Sans

The last one is probably the one with the missing symbols. IIRC, the default font was changed in F36 from DejaVu Sans to Noto Sans.
https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts

If the latter is missing symbols and installing DejaVu Sans fixes it, I think that’s something that could be filed as a bug.

I do not have a font simply named “Symbol”:

fish ⯈ fc-match "Courier"; fc-match "Times-Italic"; fc-match "Times-Roman"; fc-match "Times-Bold"; fc-match "Symbol"
NimbusMonoPS-Regular.otf: "Nimbus Mono PS" "Regular"
NimbusRoman-Regular.otf: "Nimbus Roman" "Regular"
NimbusRoman-Regular.otf: "Nimbus Roman" "Regular"
NimbusRoman-Regular.otf: "Nimbus Roman" "Regular"
StandardSymbolsPS.t1: "Standard Symbols PS" "Regular"

Now, “Standard Symbols PS” does look like it’s what I need. But like I said in my original post, Evince isn’t using it:

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.

@qulogic The switch from DejaVu to Noto was a good idea, but installing DejaVu didn’t solve the issue for me.

I did find this in the NEWS file for Evince’s source: NEWS · main · GNOME / evince · GitLab

* 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, not NotoSans-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.

1 Like

File a bug with Evince it is, thanks!

1 Like

No, to be clear, I meant to file a bug with Noto Sans in Fedora. Its fontconfig configuration does not work for the Symbols font.

1 Like

I’ve filed a bug report at 2088665 – Noto Sans is chosen to display symbol characters it doesn't contain for those interested.

1 Like