Bug 1013267 - Spacing lost in printing and print preview
Summary: Spacing lost in printing and print preview
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: evince
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-28 22:59 UTC by Matthew Saltzman
Modified: 2013-10-25 07:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-25 07:50:49 UTC
Type: Bug


Attachments (Terms of Use)
PDF that shows the problem. (112.86 KB, application/pdf)
2013-09-28 22:59 UTC, Matthew Saltzman
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.