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.
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.
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.