printed pdf file lacks item boxes

Bug #1300659 reported by Matthias Braun on 2014-04-01
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evince
Unknown
Medium
evince (Ubuntu)
High
Unassigned

Bug Description

When I print the attached pdf file, then the little green boxes used to indicate items in the itemization are missing.
The boxes are perfectly visible on screen, but when printing to a pdf file or printer or when using the pdf preview they are missing.

Sebastien Bacher (seb128) wrote :

Thank you for your bug report, that's likely a poppler issue and should be reported to https://bugs.freedesktop.org/enter_bug.cgi?product=poppler

Changed in evince (Ubuntu):
importance: Undecided → High
status: New → Confirmed

Created attachment 96712
Example of missing items when printing

When I print the attached pdf file in evince, then the little green boxes used to indicate items in the itemization are missing.
The boxes are perfectly visible on screen, but when printing to a pdf file or printer or when using the pdf preview they are missing.

I am using ubuntu x86_64 with the following packages:
ii evince 3.10.0-0ubuntu2
ii libpoppler-glib8:amd64 0.24.1-0ubuntu1
ii libpoppler43:amd64 0.24.1-0ubuntu1

Changed in evince (Ubuntu):
status: Confirmed → Triaged

As a reference: I have filled the same bug on the ubuntu bugtracker and was refered to here. http://bugs.launchpad.net/ubuntu/+source/evince/+bug/1300659

Sebastien Bacher (seb128) wrote :

thanks!

Changed in evince:
importance: Unknown → Medium
status: Unknown → Confirmed

Does pdftops produce a file with boxes you can print?

Yes using pdf2ps on the file and then opening/printing the postscript file produces the correct results.

looks like a cairo backend bug to me then

This file is a PDF intermediate file for PCB production from KICAD, when attempting to print the "pads" and some other items disappear from "print preview" and printed outputs.

This appears to be the same issue, but totally breaks the KICAD work-flow which for some items requires a PDF step.

Problem is caused by _cairo_path_fixed_stroke_extents() returning wrong extents.

Created attachment 125086
Reduced test case

Reduced test case. This PDF strokes a single path of one of the boxes in the original PDF. The original PDF draws the boxes with the fill-stroke operator "B". I've replaced it with a stroke "S".

To reproduce:

pdftocairo -ps reduced-test-case.pdf out.ps

The output does not show the box.

Created attachment 125087
Debug patch

This patch shows the problem is caused by _cairo_path_fixed_stroke_extents().

If the operation is changed to a fill (change line 259 in the PDF from "S" to "f") the box appears in the output.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/241.

Changed in evince:
status: Confirmed → Unknown
Jouni Mettala (jouni-mettala) wrote :

Can you reproduce this bug with current development version of Ubuntu? I can't. Versions are evince: 3.32.0-1 poppler-utils: 0.74.0-0ubuntu1

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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