Evince fails to display some fonts (some font thing failed)

[Sébastien Brochet]

Dear experts,

Since the upgrade to Ubuntu 15.04, evince fails to display some fonts of most of my latex pdfs. I attached an example of the pdf rendered by evince, and a screenshot of what it's supposed to look like. The console is spammed with errors:

'some font thing failed'

The pdf display correctly with xpdf and okular.

Thanks

Description: Ubuntu 15.04
Release: 15.04
evince:
  Installed: 3.14.2-0ubuntu2
  Candidate: 3.14.2-0ubuntu2
  Version table:
 *** 3.14.2-0ubuntu2 0
        500 http://ftp.belnet.be/ubuntu.com/ubuntu/ vivid/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: evince 3.14.2-0ubuntu2
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sun Apr 26 23:15:02 2015
SourcePackage: evince
UpgradeStatus: No upgrade log present (probably fresh install)

[Sébastien Brochet (blinkseb)]

The screenshot of the pdf document in okular

[Sébastien Brochet (blinkseb)]

It seems to be because of some apparmor configuration. After disabling apparmor for evince, the pdf loads fine.

I guess it's because I have texlive installed and evince tries to load the fonts from here. Maybe the default configuration for the evince profile should be more permissive?

[Sebastien Bacher (seb128)]

thanks for your bug report

reading your kernel log, it seems you have /usr/local installed fonts
"/usr/local/texlive/2014/texmf-dist/fonts/opentype/public/tex-gyre/texgyreheros-regular.otf"

the issue seems similar to bug #846639 which has been closed because having custom texlive installation is non common and if you use an unsual setups it's up to you to do the apparmor configuration adjustement to adapt to it, doing the same here

[Romano Giannetti (romano-giannetti)]

Just to add a note: it happened to me also, because I have /usr/local as a symlink to /home/local (in a different partition) and evince (or apparmor) correctly complained.

So all fonts from Microsoft, which are installed in /usr/local/font, came out blank.

Setting aa-complain solved momentarily the thing, then an edit of the profiles is recommended.

Now, 'some font thing failed' is not exactly a very informative error message... ;-)

[Mohammad Anwar Shah (mohammadanwarshah)]

I am using 17.04 and don't have texlive installed or any fonts in /usr/local. But still this happened. Needed to use `sudo aa-complain evince`

And yes, "some font thing failed" is an worst kind of debug info I've seen.

[bitinerant (bitinerant)]

I have a number of PDF files which, when opened, display some text but not others, and show dozens of "some font thing failed" lines in the terminal. The PDFs appear fine in Firefox. I don't know what "texlive" is, so I'm quite sure I'm not using that, but I do have some fonts in ~/.fonts

Thanks to the above comment, I tried:

sudo apt install apparmor-utils
sudo aa-complain evince

Now Evince displays the PDFs properly and does not show the "some font thing failed" errors.

Ubuntu 18.04, GNOME Document Viewer 3.28.2

[bitinerant (bitinerant)]

Closely related: Bug #793122

[bitinerant (bitinerant)]

I have additional information. Within ~/.fonts I have a subfolder containing some Windows fonts. It seems that if those files are not OWNED by the user running Evince (even though they are group readable), then Evince does not display the fonts at all.

I feel this is a bug. At the very least, Evince should display a permissions error to the user rather than a document with a lot of missing information. Better yet, it should display the text in another font. Better yet, apparmor should be adjusted to allow it to read these font files.

[Seth Arnold (seth-arnold)]

Nearly all the AppArmor rules provided by upstream AppArmor include 'owner' prefixes on files and directories within user home directories. This is intentional -- for example, the <abstractions/fonts> file includes:

  owner @{HOME}/.fonts.conf r,
  owner @{HOME}/.fonts/ r,
  owner @{HOME}/.fonts/** r,
  owner @{HOME}/.local/share/fonts/ r,
  owner @{HOME}/.local/share/fonts/** r,
  owner @{HOME}/.fonts.cache-2 mr,
  owner @{HOME}/.{,cache/}fontconfig/ r,
  owner @{HOME}/.{,cache/}fontconfig/** mrl,
  owner @{HOME}/.fonts.conf.d/ r,
  owner @{HOME}/.fonts.conf.d/** r,
  owner @{HOME}/.config/fontconfig/ r,
  owner @{HOME}/.config/fontconfig/** r,

  /usr/local/share/fonts/ r,
  /usr/local/share/fonts/** r,

Whoever owns the fonts in your ~/.fonts/ directory can probably gain execution privileges by whatever program is rendering the fonts.

You could store your fonts in /usr/local/share/fonts/ if they are appropriate for multiple users on the system.

Or you could amend /etc/apparmor.d/local/usr.bin.evince if you want these fonts to be available to evince without storing them in /usr/local/share/fonts/.

Thanks

[bitinerant (bitinerant)]

Seth--thanks for the helpful details.

I appreciate the suggestions, but none quite fit my use case. It's really 2 users wanting to share the fonts--one owns them and the other has a symlink. If I put them in /usr/local/share/fonts/ then they don't get backed up and can't be modified. I think the simplest option for me is to use the extra 74 MB and make a copy for each user.

I understand the execution privileges issue if the font files are owned by another user, so you've convinced me that this is a valid security precaution.

Do you agree, however, that it would be helpful to display a message for the user rather than empty space in their PDF?

[Seth Arnold (seth-arnold)]

On Sat, Oct 13, 2018 at 06:54:59PM -0000, bitinerant wrote:
> I appreciate the suggestions, but none quite fit my use case. It's
> really 2 users wanting to share the fonts--one owns them and the other
> has a symlink. If I put them in /usr/local/share/fonts/ then they don't
> get backed up and can't be modified. I think the simplest option for me
> is to use the extra 74 MB and make a copy for each user.

Heh, indeed, "fonts that might be changed" never crossed my mind!

> Do you agree, however, that it would be helpful to display a message for
> the user rather than empty space in their PDF?

Absolutely agreed. I'd expect a fallback to a font that *is* available
and a notice in a status bar that fonts have been replaced due to errors.
Nothing that would make a user *click* on anything but that would clearly
explain the issue for a user curious why a document doesn't look right.

Thanks

[Antoine Amarilli (a3nm)]

I agree that this bug is super confusing: when apparmor prevents evince from accessing a font (in my case, because of some folders in /usr/share having been symlinked to a different partition), there is no visible error message (except "some font thing failed" in the console log) and the text with the affected font is silently not rendered at all.

I agree that at the very least evince should have a visible warning that some document content was not rendered.

[Romano Giannetti (romano-giannetti)]

My solution was to apply this diff:

diff --git a/./etc-apparmor.d-abstractions-fonts b/etc/apparmor.d/abstractions/fonts
index 45cdf9a..44c54ac 100644
--- a/./etc-apparmor.d-abstractions-fonts
+++ b/etc/apparmor.d/abstractions/fonts
@@ -51,6 +51,8 @@

   /usr/local/share/fonts/ r,
   /usr/local/share/fonts/** r,
+ /home/local/share/fonts/ r,
+ /home/local/share/fonts/** r,

   # poppler CMap tables
   /usr/share/poppler/cMap/** r,

...and the reloading the profiles (sudo service apparmor reload). So if you have symlinked fonts directory, you simply have to add them to the profile.

[Romano Giannetti (romano-giannetti)]

And by the way, just if somebody is still struggling to find where the "good" error messages (instead of the surprising useful "some font thing failed"), grep for apparmor in /var/log/kern.log