Bug 1013267

Summary: Spacing lost in printing and print preview
Product: [Fedora] Fedora Reporter: Matthew Saltzman <mjs>
Component: evinceAssignee: Marek Kašík <mkasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: mkasik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-25 07:50:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
PDF that shows the problem. none

Description Matthew Saltzman 2013-09-28 22:59:40 UTC
Created attachment 804552 [details]
PDF that shows the problem.

Description of problem:
Some PDf documents display with correct whitespace, but whitespace is displayed incorrectly when printing or displaying in print preview window.

Version-Release number of selected component (if applicable):
evince-3.8.3-2.fc19.x86_64

How reproducible:
Sometimes

Steps to Reproduce:
1. Open the attached PDF.
2. Open print preview window.
3. Compare the images.

Actual results:
PDF displays correctly, but print preview runs characters together and opens large spaces compared to the correct display.

Expected results:
PDF and print preview both display correctly.


Additional info:
The image is properly displayed and printed in Adobe Reader (although it has its own problems printing).

Comment 1 Marek Kašík 2013-10-02 11:50:40 UTC
Hi,

the problem is in the PDF file. Specifically the application which created it did not placed all needed glyphs to the embedded font. The font misses glyph for space.
It shows correctly at first because the PDF contains coordinates for almost all words so the missing space is not a problem. But once you want to convert it anyhow (as done when printing) you'll encounter this problem.
Poppler converts this to a cairo surface which prefers textual information when exporting it again to PDF or PostScript.
When cairo exports the space character it doesn't have its glyph so it uses code for undefined glyph (\000 here). When such an exported PDF is processed by printer / another application (counting in Adobe Reader) it ignores the character and doesn't show it resulting in the lost spaces between words.
You can export it to PostScript at first and then print it as a workaround (PostScript processors use ".notdef" glyph in such case but PDF processors don't).
This is not a bug in evince / poppler / cairo from my point of view.

Regards

Marek