Ubuntu
evince package

evince prints lines of text at a 45 degree angle

Bug #199493 reported by Benjamin Redelings
22
Affects Status Importance Assigned to Milestone
cairo (Ubuntu)
Fix Released
High
Ubuntu Desktop Bugs
Ubuntu ubuntu-8.04-beta
evince (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Binary package hint: evince

This morning I tried printing to PS and print-preview to see how the libcairo2 upgrade may have affected evince.
For one PDF, evince now printed a few letters one line too high.
But on a scientific article that I had, it printed horizontal lines of text at roughly 45 degree angles. Printing to PDF works fine, put Print Preview and Print to File -> PS both display this problem.

evince: 2.21.91-0ubuntu1
libcairo2: 1.5.12-0ubuntu1
libpixman-1-0: 0.9.6-1

I am wondering if possibly this is a result of not upgrading libpixman to match the upgrade in libcairo2.
I also noticed that if I create a *second* PDF file using "Print to File -> PDF" and then use Print Preview on the second file, that the results are OK.

Related branches

lp:ubuntu/karmic/cairo
Revision history for this message
Benjamin Redelings (benjamin-redelings) wrote :
Revision history for this message
Benjamin Redelings (benjamin-redelings) wrote :

Here are have attached the PostScript file created by evince.

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

I can vouch for this one. gedit is fine, so this is a bug in Evince.

Changed in cairo:
status: New → Invalid
Changed in evince:
status: New → Confirmed
Revision history for this message
DualCortex (main-spam) wrote :

I can confirm this one. I printed 22 pages of notes on Fourier Series. 22 pages wasted.
Same bug occurs when printing a PDF to another PDF.

Attached is the sample output of a single page

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

Confirmed, that's a libcairo issue

Changed in cairo:
assignee: nobody → desktop-bugs
importance: Undecided → High
milestone: none → ubuntu-8.04-beta
status: Invalid → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

there is no need to write hardy in the title, it forces to rename all the bugs when hardy+1 will open and the information can go to the description anyway

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

that's not an evince bug

Changed in evince:
importance: Undecided → Medium
status: Confirmed → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cairo - 1.5.12-0ubuntu2

---------------
cairo (1.5.12-0ubuntu2) hardy; urgency=low

  * debian/patches/90_from_git_fix_pdf_printing.dpatch:
    - change from git, fix pdf printing (lp: #199493)

 -- Sebastien Bacher <email address hidden> Thu, 13 Mar 2008 12:23:25 +0100

Changed in cairo:
status: Confirmed → Fix Released
Revision history for this message
Michael B. Trausch (mtrausch) wrote :

Putting something in the title to show which release the bug was _found_ in is helpful so that it is easy to determine what the priority is for the person looking at the thing in a list. No renaming is necessary... if I found a bug in Hardy, it's going to have [Hardy] attached to it, and that shouldn't be changed. If Hardy+4 comes out and the bug is still open, well, the bug is still open. Why would it need to be renamed? The only thing bugs need is to be worked on and closed, right? :-)

A little more on-topic, when will cairo actually hit the repositories? Shouldn't bugs that have not had their fixes actually released yet be marked as fix-committed, until the repositories are updated?

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

you can write this information in the description or use tags, when we read a bug using [dapper] now it looks like a dapper specific issue when usually that's just because nobody updated the title since. Anyway I'm one of the people working on those packages and the title is something which should be useful to the maintainers not the submitter.

The bugs are closed on upload because have a status by architecture to just handle the delay before upload and build would be lot of extra complexity for now real win, the new version should be available now

Revision history for this message
Bruce Cowan (bruce89-deactivatedaccount) wrote :

I have to agree on the not putting [hardy] on the front.

Sorry for leading this bug the wrong way.

Revision history for this message
Francesco Conti (arunax165) wrote :

I don't think the bug was fixed correctly. I have an up-to-date version of Hardy 64 bit, and I'm still getting it (or something that is very similar to it). When trying to print the attached PDF, I get errors in mathematic characters. Something must be wrong in the way evince translates PDF files to PS files before sending them to the printer.

Revision history for this message
Francesco Conti (arunax165) wrote :

Here's the PS file I get from printing the PDF file above.

Revision history for this message
Francesco Conti (arunax165) wrote :

The released fix doesn't fix all issues

Changed in cairo:
status: Fix Released → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

that is a different issue, don't reopen a closed bug without a good reason, you should rather open a new bug

Changed in cairo:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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