GNOME Bugzilla – Bug 766283
Printing from evince resulted in a badly kerned serif font instead of a sans font being used
Last modified: 2018-05-22 16:38:05 UTC
Created attachment 327649 [details] Correct and mangled printer output, side by side. Let me open by saying I'm not sure if this is a bug in: evince libpoppler the HP Laserjet in our office but I have to start by reporting the bug somewhere, so here it is: The background: One of our staff submitted an document (a PDF) This document: • printed correctly with lpr from the command line on my machine • printed correctly with lpr on the reporting user's machine • printed correctly from evince on my laptop ◦ running Debian/jessie, evince 3.14.1, libpoppler 0.26.5 • printed incorrectly from evince on the user's machine ◦ same distribution and versions as my laptop The printing error [image attached] was that instead of a sans serif font being used, a serif'd one was, and its kerning was badly mangled. After some digging I discovered the following: • The PDF specified Helvetica and Helvetica Bold (core fonts) but did not embed them (as is normal for core fonts) • Evince recognised that these were in the core 14 font set and displayed the document with a substituted font instead • On the user's laptop Nimbus Sans was used • On mine TeX Gyre Heros was used • When printing from evince the substituted font was (I think) partially embedded. Certainly when saving a copy of the PDF this happened - on the users laptop tihs resulted in a PDF with Nimbus Sans partially embedded. • The printer ignored or rejected the embedded Nimbus Sans font and substituted a serif'd font with bad kerning instead • When TeX Gyre Heros was embedded, the printer coped fine So I guess the questions are: • Is it correct to replace core fonts when sending a document for printing or when saving a copy? I would lean towards not, since everything is supposed to have those fonts (or cope if not), and the printer did in fact cope when no substitute fonts were embedded. • Are the fonts being embedded badly in some way? I'm not sure if I can release the actual documents in question (I'll check and attach them here if there's nothing confidential in them). • Whose fault is it that the printer choked on the partially embedded Nimbus font? evince? libpoppler? the printer?
I should add - "save a copy" of a PDF with non-embedded core fonts results in the saved copy having the substituted fonts embedded in it, which means that the PDF has (admittedly in a way a user might not notice) been changed. I think that counts at the very least as surprising behaviour, and quite possibly as a bug (although there may be history as to why it does this of which I am not aware which justifies this behaviour more than is immediately apparent to me). Assuming it is a bug, would you be interested in a patch which altered the behaviour so that core-fonts were not substituted?
Does "Save a copy..." (in the menu) replace the fonts?
Yes, that's how I got my first clue as to what was happening.
that's very weird. Some of the things you post should not be happening... Can you attach the pdf file?
It is strange as Poppler-glib is supposed to save without changes. Nevertheless, you can try the following to narrow the issue to Poppler: $ python > from gi.repository import GObject, Poppler > doc = Poppler.Document.new_from_file("file:///path/to/document.pdf") > doc.save_a_copy('file:///tmp/foo.pdf') and check /tmp/foo.pdf That is, assuming you have installed the GObject Instrospection package for Python.
Created attachment 328555 [details] Original PDF with non-embedded fonts This is the original PDF, which specifies Helvetica but does not embed it.
Created attachment 328556 [details] The file that gets sent to the CUPS print queue (before filtering) This is what evince submits to the CUPS queue - it is identical (same md5sum) to what gets produced by printing to a file rather than to a print queue.
Ok, I can't seem to reproduce the "save a copy" font embedding, either through evince or through libpoppler directly - I can't explain that - I'm sure it was happening since that's where I noticed the problem to start with. I have attached the original PDF (I had to clear it with the user in question) and also what gets submitted to the queue: Currently the queue version has TeX Gyre Heros embedded, which _doesn't_ confuse the printer. I'm going to try and re-break the setup so that Nimbus gets embedded instead and make sure that that still confuses the printer - if it does, I will also attach _that_ PDF.
*sigh* I can get evince to embed nimbus instead but today the printer isn't mangling it. I swear that thing is sentient and evil.
Created attachment 328565 [details] This is the PDF which was being mangled by the printer but is fine today This file was captured from the print system on the user's machine. It has Nimbus embedded instead of leaving the contents unaltered. It was printing with the mangled serif font in the attached image when originally reported, but is working today (I have no explanation for this other than "printers are evil").
(In reply to Vivek Dasmohapatra from comment #10) > ..."printers are evil" Totally. +1
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/673.