Bug 91931

Summary: [pdftocairo] Wrong result after convertion
Product: poppler Reporter: Lome <devil92666>
Component: cairo backendAssignee: poppler-bugs <poppler-bugs>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: gpoo+bfdo
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Original pdf and resulting jpg
Similar problem with this pdf
Expected and resulting jpgs differ
use shape mask with soft mask

Description Lome 2015-09-09 07:36:27 UTC
Created attachment 118158 [details]
Original pdf and resulting jpg

Convertion of attached pdf files with this parameters "pdftocairo -cropbox -jpeg -singlefile" outputs wrong results(output jpeg images do not match with original pdfs).
Comment 1 Adrian Johnson 2015-09-09 09:43:05 UTC
Fix is in git. Will be in the next release.

*** This bug has been marked as a duplicate of bug 66229 ***
Comment 2 Lome 2015-10-06 08:24:03 UTC
It did not fix after release 0.36. The bug still presists.
Comment 3 Lome 2015-10-06 08:48:18 UTC
Created attachment 118704 [details]
Similar problem with this pdf

There is similar problem with this pdf. Between text and background there is a transparent box.
Comment 4 Jason Crain 2015-10-14 00:51:13 UTC
I'm not seeing anything wrong with the rendering of the first document (Original pdf and resulting jpg) using poppler 0.36.

The second document (Similar problem with this pdf) does render incorrectly, but it has to be a separate issue.
Comment 5 Lome 2015-10-14 09:13:56 UTC
I think you are opening "Original pdf" on Unix-like system where it's also not viewed correctly. If you are not then could you please tell me which version of cairo library are you using? I tried both 1.12.2 and 1.14.2. Same result.
Comment 6 Jason Crain 2015-10-14 23:05:30 UTC
The "Original PDF" was fixed in commit 72c0162258f2630a (http://cgit.freedesktop.org/poppler/poppler/commit/?id=72c0162258f2630a).  I'm running debian jessie.  I've tested it with the development version of cairo and cairo 1.14.0 from jessie.  A poppler from after this commit works and from before does not.
Comment 7 Lome 2015-10-16 07:37:35 UTC
Created attachment 118910 [details]
Expected and resulting jpgs differ
Comment 8 Lome 2015-10-16 07:38:59 UTC
Then I guess the problem is in my system or one of other libraries.
Comment 9 Jason Crain 2015-10-16 12:33:34 UTC
I see, you aren't talking about the blue oval.  Yes, I see the background image isn't showing on the left.  Near as I can tell it's something to do with a transparency group.  I'll look at it a bit more when I have time.
Comment 10 Lome 2015-11-10 14:45:42 UTC
Lately I figured out that keeping "knockout" variable always false in beginTransparencyGroup function makes pdftocairo render pdf with expected result. I think there is a problem with defining transparent object as shape though I might be wrong. Anyway this fix works for me and I didn't see it causing any bugs for other pdfs.
Comment 11 Jason Crain 2015-12-22 07:11:02 UTC
Created attachment 120648 [details] [review]
use shape mask with soft mask

The problem is that the code doesn't handle the case where both the soft mask and a knockout subgroup's shape are set.  The 'shape' pattern doesn't get destroyed when painting the subgroup so it sticks around and changes the rendering of the parent knockout group.

This patch moves some code around so the shape is cleared both when using and not using a soft mask.  The shape is propagated up to any higher level groups and the pattern is destroyed after being used.

Also fixes a memory leak I found while testing.  CairoOutputDev::beginTransparencyGroup calls cairo_reference(cairo_shape) but it's not matched by a cairo_destroy.  This removes the cairo_reference call because we already keep track of cairo_shape's lifetime with knockoutCount.
Comment 12 Jason Crain 2015-12-25 04:08:12 UTC
*** Bug 74202 has been marked as a duplicate of this bug. ***
Comment 13 Lome 2015-12-28 06:32:36 UTC
Patch provided by Jason Crain resolves the bug.
Comment 14 Adrian Johnson 2015-12-28 11:06:10 UTC
Needs to be committed before this bug can be closed.
Comment 15 Carlos Garcia Campos 2016-01-02 10:14:46 UTC
Thanks for the patch Jason, I've just pushed it.

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.