Exporting to PDF problems (reduced opacity + filter effect)

[Jaromir Coufal]

When I am exporting *.svg file from Inkscape (win32build version Inkscape21345-0905140303.7z) to PDF 1.4, and I have transparent objects as you can see on the attached file, exported PDF file has different transparency than original from inkscape. (some objects are as transparent as they are not visible more...)

[Pablo Trabajos (pajarico)]

Can't reproduce on Win XP, 0.47-pre1. We need you to attach the SVG file from which you're exporting the PDF. You might want to attach the PDF too. It's impossible to determine what kind of shape and/or attributes of the object are causing this without those files.

[Jaromir Coufal (jaromir-coufal-deactivatedaccount)]

i added necessary materials...

[su_v (suv-lp)]

reproduced with Inkscape 0.47+devel r9424 on OS X 10.5.8

after removing the filter effects (Gaussian Blur) from the objects they are visible in the exported PDF even though their opacity (10%) has not been changed -> this bug seems more related to rasterizing filter effects on export to PDF.

[su_v (suv-lp)]

Removing the object opacity and adding transparency in the filter effect (using Color matrix) produces a PDF out put close to the rendering of the SVG in Inkscape.

[su_v (suv-lp)]

… above result indicates to me that the combination of object opacity and rasterized filter effects doesn't work well in PDF export.

[Chas Hewgley (charles-hewgley4)]

Hello,

Inkscape ver.: Inkscape 0.48.0 r9654 on Mac OS 10.4.11 / PowerPC

Here are more example files for this issue. When exporting to pdf, the image plane (shaded parallelogram in the middle) will appear in the pdf if the opacity is set to 100%, but it will not appear in the pdf if opacity is set to 99%.

[su_v (suv-lp)]

@Chas - what PDF viewer do you use? In both of your PDF file the image plane is visible when viewing them in Apples's Preview on OS X 10.5.8.

There is a problem when reopening the PDFs in Inkscape, but it is not related to the issue described here ( bug #381677):
The plane with reduced opacity in the second PDF is imported as a clipped pattern (as opposed to the one with 100%) and only partially or randomly (depending e.g. on zoom level) visible, a known issue recently reported in

Bug #643093 “In imported PDF, some objects not rendered / partially rendered”:
<https://bugs.launchpad.net/inkscape/+bug/643093>

and the underlying cause a long-standing bug:
Bug #168014 in Inkscape: “Redraw fails with clipped object patterns”:
<https://bugs.launchpad.net/inkscape/+bug/168014>

[Thomas Bartosik (j-launchpad-tbart)]

more examples at this bug (sorry for the dupe, search function didn't pick this one up..):
Additional error cases include masked objects, etc.
https://bugs.launchpad.net/inkscape/+bug/828844

[su_v (suv-lp)]

New duplicate bug #828844 provides a reduced test case:
<https://bugs.launchpad.net/inkscape/+bug/828844/+attachment/2289223/+files/blur-and-opacity-object-invisible-in-pdf.tar.bz2>
(reproduced with Inkscape 0.48+devel r10554 on Mac OS X 10.5.8 (i386))

[Sparhawk (sparhawkthesecond)]

Sorry, do those tags relate to a technical meaning? I just added them to prevent further duplicates, since nothing came up when both Thomas and I searched.

[Hachmann (marenhachmann)]

This error still happens in Inkscape 0.91 and 0.92.1pre2.
Another test case SVG attached (derived from a question at https://answers.launchpad.net/inkscape/+question/455791).

[Vladimir Savic (vladimir-firefly-savic)]

I had to deal with this issue for many years. Here is what I think is the problem, but I still don't know whose bug is that...

Inkscape has to rasterize every svg effect.

1) Without added opacity, produced PDF looks like this: Image (rasterized svg effect). Period.
2) With opacity added on top of that effect (as is the situation with flag example), produced PDF looks like: Image (rasterized svg effect), one object group of that image clipped with PDF pattern (not to be confused with pattern you use in Inkscape and bitmap editing software).
That PDF pattern is just transparent image. Summary: Transparent image gets "clipped" with semi-transparent bitmap, which adds up. 50% transparency ends up clipped (think about it as masking in Inkscape terms) with another 50% transparency and you end up with 75% transparency.

I highly recommend trying Scribus layout application to test that. Install unstable 1.5.x to test much improved PDF import. After you import your PDF there, just ungroup until you are left without groups. Enjoy correct transparency.

[Michael Ots (topdo9)]

Thanks for the explanation and the workaround Vladimir, I'll look into the scribus. If the double opacity is the case than thats still a bug in my opinion. Hope development pickes it up.

[Sparhawk (sparhawkthesecond)]

Regarding finding the source of the bug, I tried embedding Inkscape *.svg images in a LaTeX file, then using pdflatex to render it as pdf shows the same issue. I'm guessing it's some shared svg->pdf library that's to blame.

I also installed scribus 1.5.2, but that workaround didn't work at all for me. I imported my PDF, ungrouped everything, then attempted to export it. Firstly, I got many errors "Error: object has transparency". Then, the exported PDF looks totally wrong. All my winding semi-opaque, blurred paths have become rectangles based on their bounding rectangle.

[Vladimir Savic (vladimir-firefly-savic)]

Can you share your svg and pdf please? I'd like to see how it behaves here.

[Eman Modnar (eman-mod)]

I've created an example.

This is how it looks ( http://imgur.com/XDkCW4r )
    - in Inkscape
    - in Firefox
    - rendered as PNG with Inkscape
    - rendered as PDF with `rsvg-convert` tool

And this is how it looks ( http://imgur.com/B0ELyzG )
when *saved as PDF* using Inkscape and then
    - imported back to Inkscape with Poppler option
    - rendered to PNG using Poppler's `pdftocairo` tool
    - opened in Firefox

[Vladimir Savic (vladimir-firefly-savic)]

You are right. It is unfortunately quite tricky with this one. :/ Hope someone will be able to solve it. I could make it behave in Scribus, but it was tedious to do so. I had to remove manually all the pattern masks and set opacity to each individual object again, which is a pain to do.

[Hector Martin (marcan42)]

I'm still getting this with 0.92. I've attached another minimal test case above. It's an SVG with 3 circles. The left circle is #000000ff with 50% object opacity, the middle circle is #0000007f, and the right circle is #7f7f7fff. They should look identical. The bottom circles are the same, but with blur applied (30%). They should all look like the same color in the SVG, and in Inkscape and Chrome they do (when opening the SVG). However, in the PDF version, the bottom left circle is much too light.

[Hector Martin (marcan42)]

I think the problem is the opacity is being triple-applied.

Looking at an ASCII-ified PDF with mutool:

$ mutool clean -a -d pdf_blur_test.pdf pdf_blur_test_aa.pdf

In the PDF, the page uses this resource dictionary:

3 0 obj
<<
  /ExtGState <<
    /a0 <<
      /CA .5
      /ca .5
    >>
    /a1 <<
      /CA .498039
      /ca .498039
    >>
    /a2 <<
      /CA 1
      /ca 1
    >>
  >>
  /XObject <<
    /x6 6 0 R
    /x7 7 0 R
    /x8 8 0 R
    /x9 9 0 R
  >>
>>
endobj

Note the three opacity GStates (/a0, /a1, /a2). /a0 is used for *both* the unblurred and blurred leftmost circles (I guess there is some deduplication; /a1 is slightly different from 0.5 due to rounding).

The page contents are:

4 0 obj
<<
  /Length 852
>>
stream
<snip>
#### this is the top left circle
1 0 0 -1 0 841.889771 cm
q
q
1 0 0 1 0 0 cm
/a0 gs /x6 Do <---- top left circle uses /a0 = opacity 0.5
Q
0 0 0 rg /a1 gs <---- top middle circle uses /a1 = opacity .498039
<snip circle outline>
0.498039 0.498039 0.498039 rg /a2 gs <---- top right circle uses /a2 = opacity 1.0
<snip circle outline>
q
1 0 0 1 0 0 cm
/a0 gs /x7 Do <---- bottom left circle uses /a0 = opacity 0.5
Q
Q q
201.207 389.941 192.859 192.859 re W n
q
192.858322 0 0 -192.858322 201.208612 582.801606 cm
/a2 gs /x8 Do <---- bottom middle circle uses /a0 = opacity 1.0
Q
Q q
358.793 389.941 192.859 192.859 re W n
q
192.858322 0 0 -192.858322 358.792416 582.801606 cm
/a2 gs /x9 Do <---- bottom right circle uses /a0 = opacity 1.0
Q
Q

If I change "/a0 gs /x7 Do" to read "/a2 gs /x7 Do" then the circle becomes darker, but still not quite dark enough. For that we have to follow the /x7 reference to the data for the bottom left circle:

7 0 obj
<<
  /Length 116
  /Resources 12 0 R
  /Type /XObject
<snip>
/a0 gs /x14 Do
Q
Q

Which uses this resource dictionary:

12 0 obj
<<
  /ExtGState <<
    /a0 <<
      /CA .5
      /ca .5
    >>
  >>
  /XObject <<
    /x14 14 0 R
  >>
>>
endobj

And here we have another /a0 with opacity .5. Changing *that* to 1 makes the bottom left circle look like how it's supposed to look. The circle uses an all-black image (object 14) with a mask at object 21, and the mask never goes above 7f.

So the opacity is baked into the bitmap when it is rasterized, but then somehow it gets applied not once but *twice* again when the bitmap is rendered. And hence it winds up much, much lighter than it should.

I guess the fix here is that when the object is rasterized, any opacity tag/attribute needs to be reset to 100% since the opacity is now baked into the bitmap.

[Hector Martin (marcan42)]

Here's a patch that fixes the issue. I'm not familiar at all with the codebase, so I'm not sure if it's the correct approach, but it seems to work for me.

It works by setting all items down to the target to 1.0 opacity when generating the raster bitmap (which fixes one chain of double-opacity) and pushes a new state (which resets opacity to 1.0) when rendering bitmap (which fixes the other instance). This means the bitmap is rasterized at 100% opacity and then opacity gets applied later.

[Patrick Storz (ede123)]

Just stumbled across this issue myself and tested the patch.

It seems to work as expected, however I think it's unnecessary to iterate over all items (which are hidden anyway)? I therefore suggest the simplified version attached unless I'm missing something.

Only nitpick (in both the original patch as well as in the one I provided):
The function "sp_generate_internal_bitmap()" which we modify to reset opacity is used by other dependent code as well. All of that code does not use the "item_only" parameter (so nothing changes at this time) but I guess we should consider an additional boolean like "reset_opacity" anyway to avoid side effects.

[Patrick Storz (ede123)]

Simplified patch committed to master
  https://gitlab.com/inkscape/inkscape/commit/1e31c41a0ef4b0f383d4f9d2941f643ae67ca646
and 0.92.x
  https://gitlab.com/inkscape/inkscape/commit/eeee5c3203891fc3254c8ef22f3d06f6317cae6a

[Hachmann (marenhachmann)]

Thank you, Patrick. I had this issue with our event program (which I had to export to png instead). Tested, and it works :)

[Patrick Storz (ede123)]

Great! Thanks for the feedback.

I actually noticed we had similar issues when exporting any other embedded bitmap image with partial transparency (i.e. not just rasterized filters) and just pushed an additional fix to master
  https://gitlab.com/inkscape/inkscape/commit/1a1d84bd83d59d80969e0f6e872a3c6da6a82673
and 0.92.x
  https://gitlab.com/inkscape/inkscape/commit/ba833b0ce5b57333b72dccad2276990809e87ae9

It partially reverts the last commit and modifies how the bitmaps are drawn onto the cairo surface (they always use full opacity now).

In the testcase I created (see attached for reference) which is mixing raster images with varying levels of opacity, grouping, as well as filter effects / masks / clips it seems to work nicely (all rectangles should be the same color).

Please let me know if this causes any regressions that might not be covered by my test though.

[Hachmann (marenhachmann)]

Tested with the same file as before (containing a couple of objects that are grouped and clipped and have Gaussian blur) - it still looks correct there after the change. Good work checking for related issues :)

I can't do any really thorough testing at the moment.

Btw. could it be that one of the two fixes listed in the release notes has a wrong link? (they link to the same report currently)

[Patrick Storz (ede123)]

> Btw. could it be that one of the two fixes listed in the release notes has
> a wrong link? (they link to the same report currently)

Actually my search didn't yield any related reports but as I mentioned both fixes in this bug I re-used the same link. I considered adding only one bullet point to the release notes, but I guess "rasterized filter effect" and "embedded bitmap image" are quite different things for many users (even though they're handled similarly by Inkscape).

[Hachmann (marenhachmann)]

I'd probably only have made one list item for it, then (it looks a bit strange to me to have two items with almost the same text and the same report linked) - doesn't mean it isn't worth two, though :)