evince prints formulas incorrect

Bug #1006263 reported by Allo
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GS-GPL
Invalid
Critical
libcairo
Fix Released
High
cairo (Ubuntu)
Fix Released
High
Unassigned
Precise
Won't Fix
High
Unassigned
ghostscript (Ubuntu)
Invalid
High
Unassigned
Precise
Invalid
Undecided
Unassigned

Bug Description

evince does not print mathematical formulas correctly in precise.

example file: http://ddg.cs.columbia.edu/SIGGRAPH06/DDGCourse2006.pdf
try to print page 60, look at the formula S(t) in the upper left part, or at the S(i_0, i_1, i_2, i_3) in the middle-left. There are all symbols missing: "(", ")", "-", ","

when i print to .ps, evince still shows the file right, but when i submit it with "lp" to the printer, the problem is the same as when printing directly from evince.

as a counterexample, when i print the page to .ps from okular and then submit it with lp, it gets printed correctly. Printing directly from acroread works, too.

This bug is a regression from lucid, where the same file is printable on the same printer with the same drivers from evince.

Revision history for this message
Allo (allo) wrote :

with page 60, i mean page 60 of the pdf, numbered 57 in the document.

Revision history for this message
Sebastien Bacher (seb128) wrote :

reassigning to cups since the the submitter wrote

"when i print to .ps, evince still shows the file right, but when i submit it with "lp" to the printer, the problem is the same as when printing directly from evince."

affects: evince (Ubuntu) → cups (Ubuntu)
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

It is a Ghostscript problem, submitting upstream.

If your printer is a PostScript printer you can install the proposed fix of bug 994477 (cups-filters package) as a workaround.

affects: cups (Ubuntu) → ghostscript (Ubuntu)
Changed in ghostscript (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :
Changed in cairo (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Added Cairo task, as Acrobat/Adobe Reader does not display the symbols, too (I had IRC discussion with Ghostscript developers on #ghostscript on Freenode and they tested with the Adobe software). With even the software from Adobe not displaying the file correctly we can assume that the file is broken and evince uses Cairo for its print output.

Revision history for this message
Allo (allo) wrote :

with acroread NOT installed via ubuntu-repos, i can see and print the characters. But its a static linked executable, so maybe cairo or whatever this one is using is linked in, too.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Example for broken page: Page 60 as evince sends it. Used "Print to file" with PDF as output format and only page 60 selected. Poppler (evince) displays the page correctly, with Ghostscript and Adobe Reader the symbols are missing.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks Till, do you think you could open a cairo bug on https://bugs.freedesktop.org/enter_bug.cgi?product=cairo as well?

Changed in gs-gpl:
importance: Unknown → Critical
status: Unknown → Confirmed
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Alexander, yes, the original file (your attachment) displays and prints with Adobe's software, the missing symbols appear only with the evince(Cairo)-mangled version (my attachment). Therefore I have added a Cairo task.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

See the following Ubuntu bug

https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1006263

The file attached there (also attached here) is printed with evince, which uses Cairo to generate the PDF output stream which gets sent to CUPS. There Ghostscript renders it and on the printout symbols in the formulas are missing.

I have reproduced it as follows:

Opened the original PDF file (attached) with evince, File/Print, "Print to file", PDF as output format, only page 60. This gives the (also attached) sample page. If you display this page with Adobe Reader or Ghostscript you will see the missing symbols ("(", ")", "-", ",") in the formulas, especially S(t) in the upper left part, or S(i_0, i_1, i_2, i_3) in the middle-left.

Only Poppler displays the sample page correctly.

As even the Adobe software does not display the page correctly, we assume the PDF to be broken and therefore a bug in Cairo.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Attached original file to preserve history.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :
Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

seb128, done, forwarded upstream as

https://bugs.freedesktop.org/show_bug.cgi?id=50496

Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

I tested the file with both 1.10.2 and 1.12.2. I can reproduce the bug with 1.10.2 but not with 1.12.2. So the bug is fixed in the current stable release.

Revision history for this message
In , Till Kamppeter (till-kamppeter) wrote :

Adrian, can you find out which commit fixed the bug, so that one can provide a patch for Ubuntu Precise?

Revision history for this message
Sebastien Bacher (seb128) wrote :

upstream says it's fixed in the quantal version of cairo, still we should look at backporting the fix to the precise one

Changed in cairo (Ubuntu):
status: Confirmed → Fix Released
Changed in cairo (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
Revision history for this message
In , Adrian Johnson (ajohnson-redneon) wrote :

You can use git bisect to find the commit. Unfortunately I don't have the time to support old versions of cairo. A lot has changed in the font subsetting since 1.10.

There is unlikely to be a simple commit that fixed the problem. It is more likely the result of the changes to support latin subsets or the changes to Type 1 fonts (which the test file uses a lot of) to support subsetting subroutines. None of this can be easily backported.

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

Closing Ghostscript task as Ghostscript developers say that the PDF from Cairo is broken. See the linked Ghostscript upstream bug.

Changed in ghostscript (Ubuntu):
status: Confirmed → Invalid
Changed in ghostscript (Ubuntu Precise):
status: New → Invalid
Changed in libcairo:
importance: Unknown → High
status: Unknown → Fix Released
Changed in gs-gpl:
status: Confirmed → Invalid
Revision history for this message
Steve Langasek (vorlon) wrote :

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release

Changed in cairo (Ubuntu Precise):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.