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).
Fix is in git. Will be in the next release. *** This bug has been marked as a duplicate of bug 66229 ***
It did not fix after release 0.36. The bug still presists.
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.
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.
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.
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.
Created attachment 118910 [details] Expected and resulting jpgs differ
Then I guess the problem is in my system or one of other libraries.
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.
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.
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.
*** Bug 74202 has been marked as a duplicate of this bug. ***
Patch provided by Jason Crain resolves the bug.
Needs to be committed before this bug can be closed.
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.