Look at it here: http://www.schokokeks.org/~hanno/plakat_lug.pdf created out of http://www.schokokeks.org/~hanno/plakat_lug.sla How it was created: Inserted an svg with transparency (on the shadow) into scribus, created a pdf with default options. Both kpdf and evince show the shadow just black, adobe reader shows correctly.
The url is no longer valid.
But still persists: http://files.hboeck.de/plakat_lug.pdf
The reference document is 404 again. Hanno: can you test with a recent version of poppler (ideally poppler HEAD) to see if this is still a problem? Also, can you add the document as an attachment to this bug?
Created attachment 12982 [details] wrong displayed pdf file
It's still displayed wrong, although it looks a bit different than before.
Using poppler head, this looks OK, except that there is something wrong with the graduated area under the feet of Tux, with a set of concentric lines through the graduation. So I think we are doing the graduation about right, except for those graduated lines. Hanno: does this match your understanding of the problem? I'm not sure why the graduated lines are there though. Perhaps some kind of overflow/underflow in the calculations?
Hi, it seems I'm having this problem too. openSUSE 11.1 with kde4.3 (okular) I created an image with Inkscape that includes pixel data and vector objects. Making a vector object semi transparent using the "opacity" option of inkscape creates trouble, using the alpha-channel to do so works. All of the created pdf documents display just fine using: - evince - adobe acrobat reader opacity creates transparency for the whole vector object including filling and the lines. going the alpha-channel way allows for individual control of transparency for filling and the lines. in the reference image for opacity also the black outline of the green object is somewhat transparent (looks gray). in the alpha-channel image only the green filling is transparent, the green outline has RGBA data of (0,255,0,1) and is therefore fully saturated / not transparent. The filling has something like (0,255,0,0.5) and is therefore semitransparent. All the other parts of the image are just pixel-data and were imported to inkscape as a png screenshot. (attachments comming right up)
Created attachment 28571 [details] transparency via alpha-channel (works)
Created attachment 28572 [details] transparency via inkscape "opacity"
Created attachment 28573 [details] reference screenshot
Created attachment 31276 [details] [review] Patch that fixes the problem in cairo backend This patch fixes the problem in document attached to comment #4.
Documents attached to comments #8 and #9 work perfectly wuith current poppler. Albert, is this an issue in splash? I think this is cairo-only.
Document from #4 has a very minor issue in splash but can mostly be qualified as "works", documents #10 and #11 also work (i think)
Moving to cairo backend then.
I've just pushed the patch.
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.