printed pdf file lacks item boxes

[Matthias Braun]

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)]

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

[Matthias Braun (matze-braunis)]

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

[Matthias Braun (matthias-braun-kit)]

I opened https://bugs.freedesktop.org/show_bug.cgi?id=76897

[Matthias Braun (matze-braunis)]

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)]

thanks!

[Albert Astals Cid (aacid)]

Does pdftops produce a file with boxes you can print?

[Matthias Braun (matze-braunis)]

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

[Albert Astals Cid (aacid)]

looks like a cairo backend bug to me then

[will munns (william-munns--launchpad)]

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.

[will munns (william-munns--launchpad)]

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

[Adrian Johnson (ajohnson-redneon)]

Problem is caused by _cairo_path_fixed_stroke_extents() returning wrong extents.

[Adrian Johnson (ajohnson-redneon)]

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.

[Adrian Johnson (ajohnson-redneon)]

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 (gitlab-migration)]

-- 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.

[Jouni Mettala (jouni-mettala)]

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