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 318920 - Some PDFs don't print okay (embedded font problem?)
Some PDFs don't print okay (embedded font problem?)
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: general
0.4.x
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-15 06:55 UTC by Arun Raghavan
Modified: 2005-12-22 07:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Sample PDF generated by Reportlab (9.92 KB, application/x-gzip)
2005-12-08 04:28 UTC, Danielle Madeley
Details
PS output from Evince (11.65 KB, application/x-gzip)
2005-12-08 04:28 UTC, Danielle Madeley
Details
PS output from Xpdf (12.47 KB, application/x-gzip)
2005-12-08 04:29 UTC, Danielle Madeley
Details

Description Arun Raghavan 2005-10-15 06:55:27 UTC
Distribution/Version: Gentoo

Reproduce (the bug, silly):
1) Open with evince: http://gradstudy.rutgers.edu/pdf/2005recommend.pdf
2) The PDF looks okay on screen
3) Print (to printer or PS) - the file gets printed using some monotype font
4) Open, print with GPDF - the file prints fine

There seem to be some embedded fonts in the PDF, might this be the problem?
Comment 1 Germán Poo-Caamaño 2005-10-17 13:27:23 UTC
I can't reproduce the problem in Ubuntu Breezy using evince 4.2.
It prints fine (both printer and PS), and it looks almost the same as 
screen.  I said "almost" because I printed out in a black & white printer.

The properties window show me 3 fonts used, one of them is not incrusted.

NewCenturySchlbk-Roman Type I, not incrusted.
Swis721BT, TrueType, Subset incrusted.
Swis721BT,Bold, TrueType, Subset incrusted.

May be is missing some font.
Comment 2 Arun Raghavan 2005-10-18 04:24:11 UTC
A number of things I noticed:

1) Cairo is not being used by the Gentoo ebuild - I will follow this up. Might
this be an issue?

2) I'm on evince 0.4.0, with poppler 0.4.2

3) I don't know much about PDFs, but if some font were missing, wouldn't gpdf
also have the same issue?
Comment 3 Daniel Kasak 2005-10-20 02:14:38 UTC
I've got the same problem here.

An internally created PDF prints perfectly with Acrobat 7 under Linux.
It prints *almost* perfectly with gpdf.
In evince, however, it prints with a number of issues - one of them is the font
is some strange monospaced font - other issues are outside the scope of this bug.

I can edit out sensitive data and attach the pdf if people like. Should I? I'll
only do it if requested, as there is already an example attached to this bug.
It's possible that my PDF will be a lot simpler, since it's rendered with a
home-grown script which is quite simple.
Comment 4 Justin Yackoski 2005-11-04 14:24:07 UTC
I am also experiencing this with gentoo using evince 0.4.0 and poppler 0.4.1. 
Some (but not necessarily all) fonts in a document are displayed using an ugly
monospaced serif font, the characters are also bunched together if they use that
font, and some symbols aren't printed correctly.
Comment 5 Ed Anderson 2005-11-22 20:00:09 UTC
I can reproduce this bug, building from source with evince 0.4.0 and poppler 0.4.2.

I had the exact same problem with the fonts not being included in postscript
files and when printing, until I compiled with --enable-cairo-output.  This
fixed the problem.

This tells me that there's some issue with the ghostscript backend.
Comment 6 Ed Anderson 2005-11-22 22:31:17 UTC
nevermind, apparently --enable-cairo-output isn't fixing the problem after all.
 I thought I had it working, but can't reproduce my fix at all.
Comment 7 Tom Cross 2005-12-05 20:11:23 UTC
I am able to re-produce this bug.  I generate my own PDF's using a perl script
using the PostScript::Elements library and then ps2pdf.  ALL of my PDFs created
this way look fine on the screen in evince, look fine when printed using "lpr
filename.pdf" but look awful when printed using evince.
Comment 8 Tom Cross 2005-12-05 20:12:32 UTC
Ugh, forgot any kind of useful info:

I'm on Fedora Core 4 which uses:

evince-0.4.0-1.2
poppler-0.4.1-1.1
Comment 9 Danielle Madeley 2005-12-08 04:26:29 UTC
I have reproduced this (also on FC4).

PDFs are generated with Reportlab. They appear to render correctly on screen,
but incorrectly when printed/exported to PS. Xpdf exports to PS fine.
Comment 10 Danielle Madeley 2005-12-08 04:28:02 UTC
Created attachment 55768 [details]
Sample PDF generated by Reportlab
Comment 11 Danielle Madeley 2005-12-08 04:28:41 UTC
Created attachment 55769 [details]
PS output from Evince

Notice how all of the fonts are wrong, this is also how it prints
Comment 12 Danielle Madeley 2005-12-08 04:29:14 UTC
Created attachment 55770 [details]
PS output from Xpdf
Comment 13 Peter Szabo 2005-12-20 15:03:31 UTC
I experienced this strange behaviour (print with weird monospace instead of the specified font, on screen is okay), must be a poppler bug, because i upgraded from  poppler-0.4.2-3 (-3 means the third rebuild of this package) to  poppler-0.4.3-1 and the problem went away. Evince was evince-0.4.0-2, for both times, before and after upgrade.

I'm using Frugalware linux, -current (i686) branch.

Happy hacking!

---
Pete
Comment 14 Kristian Høgsberg 2005-12-21 16:39:02 UTC
This bug should be fixed in poppler-0.4.3, please update and verify.  Thanks, Kristian.
Comment 15 Arun Raghavan 2005-12-22 02:59:50 UTC
Tried with poppler-0.4.3 (with cairo enabled) -- the originally reported PDF renders fine in both PS and on paper.

Thanks!
Comment 16 Nickolay V. Shmyrev 2005-12-22 07:11:58 UTC
Ok, thanks to everyone