PDF export adds page-sized clipping masks for objects with opacity < 100%

[crusaderv83]

export the picture in the attachment to pdf via cairo, open it and enjoy the slideshow!

the grey circles were produced with the circle tool, the black ones with CTRL-"pencil".

[crusaderv83 (s-kegel)]

i think the problem is cairo, not inkscape.
when i save the picture as eps or ps, the image constuction is fast.

i'm using inkscape 0.46 on windows-xp.

[Pablo Trabajos (pajarico)]

> export the picture in the attachment to pdf via cairo, open it and enjoy the slideshow!
open it where? in Inkscape? or other PDF reader? Opening the produced PDF in rev. 22040 brings it to its knees. Acrobat takes a while for displaying what seems a rather simple drawing.

[Pablo Trabajos (pajarico)]

The problem with the PDF is that for every gray circle there is a group and inside each group a couple of a path (I'm guessing the circle) and a clipping path that is the size of the page. The SVG seems fine so it is a bug in the export code.

[su_v (suv-lp)]

The grey circles all have opacity set to 99% - change it to 100% and the exported PDF is rendered as fast as expected.

[Pablo Trabajos (pajarico)]

So it is a bug, right? do you have any explanation?

[su_v (suv-lp)]

I was counting on your expertise ;-)

Attached test case shows that the nested groups and clipping masks only are created for shapes with opacity < 100.0 but not for shapes with transparency . Whether it is a bug in the exporter or PDF has no other way to store opacity information I don't know...

[su_v (suv-lp)]

...and re-opened with Inkscape.

[su_v (suv-lp)]

forgot to add: Inkscape 0.46+devel r22115 on OS X 10.5.8

PDF export settings:

  Rasterize filter effects: x
  Resolution for rasterization: 90dpi

[Pablo Trabajos (pajarico)]

suv: I added a rectangle to your example and converted them to paths to see if that made a difference. No luck. Opening back my example in PDF format there is:
-A main group
-Objects with opacity 100% and text boxes
-8 objects,almost identical, one for every path with opacity=!100, grouping two objects:
|---One of them disappears after ungrouping, so I don't know its nature
|---The other is a group of two objects, masked
     |---A group of one object, clipped
     | |---The clipping path, a black four-node box
     | |---Another group containing one object, a white four-node box, same size, fill 50% opacity
     |
     |---A group of two objects
           |---One of them disappears after ungrouping
           |---The other is a group of one object, fill is a pattern like one of the shapes

I might missed something, but just shows how broken the output is. Also, masked objects -or groups which include them- are glitched: zoom or movement makes them disappear.

[Pablo Trabajos (pajarico)]

I tried to export to PDF from 0.46 and opening exported file in 22040. Result: at a quick glance it seems like the same problem so is not a regression.

[su_v (suv-lp)]

transparency: applies to fill or stroke, separately
(master) opacity: applies to fill&stroke, single objects or groups

I will create another testcase with fill and stroke attributes, but from what I understand the reason for the clipping mask construct could be the potential complexity of groups with opacity < 100%.

Question: why use 'opacity' (unintentional?) if the goal is at most to change the transparency of the fill attribute of the circles. In this situation I see no benefit in applying opacity.At the moment I tend towards 'user error' not export (inkscape or cairo) or import (poppler) bug.

[su_v (suv-lp)]

Bug #378760 “Printing pages with objects with opacity != 1.0 gives bad results”
<https://bugs.launchpad.net/inkscape/+bug/378760>

possibly related bug explaining the page-size of the mask/clipping path (besides that the bitmap fallback doesn't happen here)?

[su_v (suv-lp)]

PS export:
- renders as bitmap for all objects with transparency or opacity. This
  explains 'image construction is fast' as mentioned in comment #2.

PDF export:
- 'Preview.app' (OS X default pdf-viewer) renders the PDF exactly as the
  SVG in Inkscape and FireFox 3.5
- 'display' (ImageMagick 6.5.5, Ghostscript 8.64) renders opacity in PDF
  flat i.e. ignoring fill and stroke transparency values of objects with
  opacity < 100.0
- I could not test a poppler-based pdf-viewer (like 'evince')

PDF re-import:
- broken, resulting SVG is rendered incorrectly in Inkscape and
  FireFox 3.5 (note: the PDF preview in the import dialog looks ok)

1) pdf export of objects with opacity seems (visually) correct
2) pdf re-import (poppler) fails

(Inkscape r22148, OS X 10.5.8, export/import settings: default)

[Adrian Johnson (ajohnson-redneon)]

The slow PDF rendering is probably a cairo bug.

PDF does not have an direct equivalent to SVG opacity. Instead the stroke and fill need to be drawn in a group and then the group is drawn with a mask (the mask is the opacity alpha).

The problem is cairo is creating the group and the mask the same size as the page. The PDF renderer creates a bitmap image for both the group and the mask, draws the group and mask, then composites the group/mask on to the page. When there are a lot of these groups on a page the rendering is going to be slow.

I'm planning to fix cairo to ensure the group and mask are the smallest possible size to minimize the work the renderer has to do.

If you are seeing rendering problems with different viewers, it is a good idea to check the PDF with acroread. Many PDF viewers have bugs and/or have not implemented all of the PDF specification. If you find a PDF that works with acroread but fails with another PDF viewer I suggest filing a bug with the PDF viewer.

[Pablo Trabajos (pajarico)]

>PDF does not have an direct equivalent to SVG opacity.
Adrian: I don't understand what you mean with "opacity" here. Opaque objects can be rendered in PDF just right and transparency is supported since PDF 1.4. Is my understanding that mask shouldn't be needed, unless I'm missing some technical explanation of how every implementation understands what's opaque and what's transparent. Please, enlighten me ;)

Regards.

[Adrian Johnson (ajohnson-redneon)]

There are two ways of creating transparent colors in PDF.

The first is to set the color (including alpha) for strokes and fills. In Inkscape this is like adjusting the color (including alpha) in the fill and stroke properties while leaving opacity at 100%. As the stroke is drawn after the fill you will see that setting alpha < 100% on the stroke makes the fill partially visible underneath. If instead you leave the fill and stroke alpha at 100% and reduce the opacity to 50% you will see that the entire object has 50% alpha but the part of the fill underneath the stroke is not visible. It is not possible to recreate this in PDF by only adjusting the stroke and fill colors just as it is not possible in Inkscape to create the exact same effect by leaving opacity at 100% and adjusting only the fill and stroke colors.

The second method of creating transparency in PDF is with a mask (SMask or soft mask in PDF terms). This involves drawing one or more objects in a group (called the transparency group), draw one or more objects in another group (called the SMask), then setting the SMask on the graphics state before drawing the transparency group. Either the luminosity or alpha of the SMask group can be used to mask the transparency group.

The opacity feature in SVG can be emulated in PDF by creating an SMask containing a solid fill where the alpha of the fill color is the same as the opacity. The fill and stroke are drawn in a tranparency group then the group is drawn on to the page with the SMask set in the graphics state.

[[e-mail] (joakim-verona)]

Just to add a data point. I have an inkscape drawing that I convert to PDF to go to a print shop. It renders well in all PDF renders I have EXCEPT far acroread which the printshop of course uses.

In acroread rendering is horribly slow so I cant actually print my document.

[[e-mail] (joakim-verona)]

I used a workaround that might help others. I opened the Inkscape PDF in Evince. Then I printed to a new pdf using Evince. The resulting transormation somehaw helps even if its of course unclear why.

[Adrian Johnson (ajohnson-redneon)]

I've fixed cairo to use the smallest possible bounding box for PDF patterns and objects instead of the page size bounding box. This fix will be in cairo 1.12 when it is released.

I've attached sample PDF output for the test case that now uses tight bounding boxes.

[jazzynico (jazzynico)]

Speed issue confirmed on Windows XP, trunk revision 11856 (cairo 1.11.2 from the devlibs).
Not reproduced with trunk revision 11871 and cairo 1.12.8 (local test).

[jazzynico (jazzynico)]

Fixed for win32, devlibs revision 46.

[jazzynico (jazzynico)]

Due to regressions (including noticeable slowness), I'm reverting cairo to the previous version (1.11.2).

[jazzynico (jazzynico)]

Cairo (1.14.6) and Pixman (0.34.0) updated in the official win32 devlibs rev. 61.