Bug 39653 - PDF: stroke is unclipped if fill precedes clip
Summary: PDF: stroke is unclipped if fill precedes clip
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.10.3
Hardware: Other All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-28 18:52 UTC by Ethan Tira-Thompson
Modified: 2011-07-29 04:42 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
sample code to demonstrate the bug (1.32 KB, application/octet-stream)
2011-07-28 18:52 UTC, Ethan Tira-Thompson 		Details
The incorrect pdf output (1.04 KB, application/pdf)
2011-07-28 18:53 UTC, Ethan Tira-Thompson 		Details
The expected PNG output (3.52 KB, image/png)
2011-07-28 18:53 UTC, Ethan Tira-Thompson 		Details
View All

Description Ethan Tira-Thompson 2011-07-28 18:52:00 UTC 
Created attachment 49694 [details]
sample code to demonstrate the bug

In the attached sample code, the left and right sides should be the same, and in PNG output they are.

However, in PDF output, the right side is 'broken': the stroke is produced un-clipped.  The order of the fill and clip commands shouldn't matter (AFAIK) because the fill is only within the path that is also being clipped.
Comment 1 Ethan Tira-Thompson 2011-07-28 18:53:07 UTC 
Created attachment 49695 [details]
The incorrect pdf output
Comment 2 Ethan Tira-Thompson 2011-07-28 18:53:31 UTC 
Created attachment 49696 [details]
The expected PNG output
Comment 3 Adrian Johnson 2011-07-29 04:42:56 UTC 
Fixed in master with http://cgit.freedesktop.org/cairo/commit/?id=c1b0e73578fe2528c8e68e309fd602acaef42e67

The fill and stroke were combined to use the PDF fill-stroke operator but cairo was not noticing that the clip had changed between the fill and stroke.

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.