Bug 76897 - printed pdf file lacks item boxes
Summary: printed pdf file lacks item boxes
Status: RESOLVED MOVED
Alias: None
Product: cairo
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-01 10:51 UTC by Matthias Braun
Modified: 2018-08-25 13:52 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Example of missing items when printing (27.61 KB, application/pdf)
2014-04-01 10:51 UTC, Matthias Braun
Details
Reduced test case (19.80 KB, application/pdf)
2016-07-15 11:39 UTC, Adrian Johnson
Details
Debug patch (470 bytes, patch)
2016-07-15 11:42 UTC, Adrian Johnson
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Braun 2014-04-01 10:51:52 UTC
Created attachment 96712 [details]
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
Comment 1 Matthias Braun 2014-04-01 11:06:44 UTC
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
Comment 2 Albert Astals Cid 2014-04-01 23:16:57 UTC
Does pdftops produce a file with boxes you can print?
Comment 3 Matthias Braun 2014-04-02 08:46:48 UTC
Yes using pdf2ps on the file and then opening/printing the postscript file produces the correct results.
Comment 4 Albert Astals Cid 2014-04-02 22:12:37 UTC
looks like a cairo backend bug to me then
Comment 5 Adrian Johnson 2016-07-15 11:31:54 UTC
Problem is caused by _cairo_path_fixed_stroke_extents() returning wrong extents.
Comment 6 Adrian Johnson 2016-07-15 11:39:18 UTC
Created attachment 125086 [details]
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.
Comment 7 Adrian Johnson 2016-07-15 11:42:02 UTC
Created attachment 125087 [details] [review]
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.
Comment 8 GitLab Migration User 2018-08-25 13:52:28 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.