evince and pdftocairo not following poppler's nor fontconfig's font substitution rules
Hello,
I have initially filed this issue against Evince ([1] which is now confidental), but in the course of the discussion it turned out the bug is somewhere in poppler itself instead, since even its own pdftocairo renders the document with the same artifacts that I have seen in evince.
I have received a PDF document which is written (mostly) in Arial. No problem, I don't have Arial installed, but I have a substitution font "Arimo" available and both fontconfig and poppler are reporting they are going to use this instead of Arial:
$ fc-match Arial
Arimo-Regular.ttf: "Arimo" "Regular"
pdffonts test.pdf
name type encoding emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
Arial TrueType WinAnsi no no no 9 0
Arial,Bold TrueType WinAnsi no no no 10 0
Arial TrueType WinAnsi no no no 11 0
Arial,Bold TrueType WinAnsi no no no 12 0
Arial TrueType WinAnsi no no no 14 0
Arial TrueType WinAnsi no no no 15 0
Arial,Bold TrueType WinAnsi no no no 16 0
Arial,Bold TrueType WinAnsi no no no 20 0
3of9Barcode CID TrueType Identity-H no no yes 21 0
CourierNew TrueType WinAnsi no no no 22 0
Arial CID TrueType Identity-H no no yes 23 0
$ pdffonts -subst test.pdf
name object ID substitute font substitute font file
------------------------------------ --------- ------------------------------------ ------------------------------------
Arial 9 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 10 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial 11 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 12 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial 14 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial 15 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttf
Arial,Bold 16 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
Arial,Bold 20 0 Arimo Bold /usr/share/fonts/truetype/croscore/Arimo-Bold.ttf
3of9Barcode 21 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
CourierNew 22 0 Cousine /usr/share/fonts/truetype/croscore/Cousine-Regular.ttf
Arial 23 0 Arimo /usr/share/fonts/truetype/croscore/Arimo-Regular.ttfEvince, however, does not use Arimo as a substitute for Arial, but NimbusSans-Regular instead which is part of the 35 Ghostscript Core fonts by URW++. This font, however, does not feature the same glyphs as Arial/Arimo, which leads to certain parts of the document being misrendered, e.g. the missing EUR currency glyph in the "Betrag in Höhe von ..." field.
The versions of all the involved packages are as follows:
$ dpkg -l {evince,libpoppler*,libharfbuzz*,libfontconfig*} | awk '/^ii/{print $2 " " $3}'
evince 3.32.0-2
libfontconfig1:amd64 2.13.1-2+b1
libharfbuzz-icu0:amd64 2.6.1-3
libharfbuzz0b:amd64 2.6.1-3
libpoppler-cpp0v5:amd64 0.71.0-5+b1
libpoppler-glib8:amd64 0.71.0-5+b1
libpoppler82:amd64 0.71.0-5+b1In the original evince bug report, Jason Crane stated the following: " Jason Crain Jason Crain @jcrain · 1 month ago Developer
I think I see what poppler is doing. It defines Arial as being an alias for Helvetica, so it searches for Helvetica instead.
I'm going to guess that your PDF is "broken", at least I would probably consider it broken, since it has probably embedded Arial glyph IDs and is using those to look up glyphs. I'm not sure if even Arimo has that level of compatibility with Arial, so possibly the only way it would render correctly is if it uses the real Arial font. "
I am attaching the document here. After all, it's just a repair invoice for my coffee machine. This is the non-confidental pendant to #838 (closed).
- Fabian