After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766283 - Printing from evince resulted in a badly kerned serif font instead of a sans font being used
Printing from evince resulted in a badly kerned serif font instead of a sans ...
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: PDF
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-05-11 15:37 UTC by Vivek Dasmohapatra
Modified: 2018-05-22 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Correct and mangled printer output, side by side. (686.46 KB, image/png)
2016-05-11 15:37 UTC, Vivek Dasmohapatra
Details
Original PDF with non-embedded fonts (57.42 KB, application/pdf)
2016-05-26 12:19 UTC, Vivek Dasmohapatra
Details
The file that gets sent to the CUPS print queue (before filtering) (40.76 KB, application/pdf)
2016-05-26 12:21 UTC, Vivek Dasmohapatra
Details
This is the PDF which was being mangled by the printer but is fine today (45.77 KB, application/pdf)
2016-05-26 16:14 UTC, Vivek Dasmohapatra
Details

Description Vivek Dasmohapatra 2016-05-11 15:37:30 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?
Comment 1 Vivek Dasmohapatra 2016-05-25 17:59:53 UTC
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?
Comment 2 Germán Poo-Caamaño 2016-05-25 18:14:01 UTC
Does "Save a copy..." (in the menu) replace the fonts?
Comment 3 Vivek Dasmohapatra 2016-05-25 18:48:07 UTC
Yes, that's how I got my first clue as to what was happening.
Comment 4 José Aliste 2016-05-25 21:11:25 UTC
that's very weird. Some of the things you post should not be happening... Can you attach the pdf file?
Comment 5 Germán Poo-Caamaño 2016-05-26 01:43:11 UTC
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.
Comment 6 Vivek Dasmohapatra 2016-05-26 12:19:15 UTC
Created attachment 328555 [details]
Original PDF with non-embedded fonts

This is the original PDF, which specifies Helvetica but does not embed it.
Comment 7 Vivek Dasmohapatra 2016-05-26 12:21:25 UTC
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.
Comment 8 Vivek Dasmohapatra 2016-05-26 12:25:38 UTC
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.
Comment 9 Vivek Dasmohapatra 2016-05-26 12:42:31 UTC
*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.
Comment 10 Vivek Dasmohapatra 2016-05-26 16:14:30 UTC
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").
Comment 11 Germán Poo-Caamaño 2016-05-26 16:24:24 UTC
(In reply to Vivek Dasmohapatra from comment #10)
> ..."printers are evil"

Totally. +1
Comment 12 GNOME Infrastructure Team 2018-05-22 16:38:05 UTC
-- 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.