Bug 13841

Summary:	Printing of PDF gives corrupted output
Product:	cairo	Reporter:	Carlos Garcia Campos <carlosgc>
Component:	pdf backend	Assignee:	Kristian Høgsberg <krh>
Status:	RESOLVED FIXED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium	CC:	karllinuxtest.relton
Version:	1.5.5
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Carlos Garcia Campos 2007-12-28 05:30:00 UTC

Bug forwarded from Evince: http://bugzilla.gnome.org/show_bug.cgi?id=503879

"Please describe the problem:
A certain PDF displays properly, but when printed certain text lines have
garbled output.

This can be seen even by 'Printing to PDF' in evince and looking at the
resulting PDF.

Note that sending the original PDF direct to the printer via CUPS lp command
(i.e.  lp file.pdf) it prints correctly.

Steps to reproduce:
1. Open certain pdf file in evince
2. Print to PDF in evince
3. View output pdf file


Actual results:
Resulting pdf has a couple of lines of garbled text

Expected results:
All lines of text should match original!

Does this happen every time?
Every time - on certain pdf files"

There is a pdf test case attached to the original bug report.

Comment 1 Karl Relton 2008-01-19 02:15:51 UTC

I'm seeing this bug alot now on PDF documents created by OpenOffice. I think a common factor is bullet points in the original openoffice document.

Comment 2 Adrian Johnson 2008-01-19 07:17:00 UTC

Fixed with this commit:

http://gitweb.freedesktop.org/?p=cairo;a=commit;h=8887fb35936bb48acadc19a0c71d1b81ec8b481d

The problem was that the PS and PDF surfaces were not correctly embedding Type 1 fonts when applications are using glyph 0 (the undefined character glyph).

In the PDF attached to the gnome bugzilla, the last bullet point on the page is using the Times Roman font. The font is not embedded and the PDF specifies the encoding of this font to be WinAnsiEncoding. The last word 'Eden' has the character 0x1c just before 'Eden' and 0x1d just after. These characters do not exist in the WinAnsiEncoding encoding so the PDF does not comply with the PDF specification. Poppler correctly substituted these two characters with glyph 0 which cairo was not correctly handling.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.