Slow pdf rendering for some graphics with pattern fills

[pepe]

For some special svg graphics that I use in inkscape, the exported PDFs render extremely slow in all readers. Only acrobat can manage them. It may be an issue with transparency, because some viewers also render those pictures wrong.

A sample file is attached. The problem is rather urgent, I would appreciate some workaround. I tried exporting to ps/eps and converting to pdf but the results are the same and/or the pictures get damaged.

[su_v (suv-lp)]

Slow rendering partially reproduced in external PDF viewers with PDF exported using Inkscape 0.48.1 and 0.48+devel r10531 (cairo 1.10.2) on Mac OS X 10.5.8 (i386):

a) Apple's PDF viewer (Preview.app) and xpdf version 3.02 have no issues with displaying the PDF,
b) Evince 2.30.3 hangs when displaying the PDF file, as does Inkscape itself (tested with r10531).

Possibly a (pattern/clip-path related) bug in poppler-based PDF viewers/importers (the clipart drawings in the SVG file have bitmap images used as patterns for clipped paths).

Please
a) provide information about your OS/platform and Inkscape version used to export to PDF
b) information about "all readers" (apart from adobe reader)
c) attach the PDF itself used for testing other PDF viewers

[su_v (suv-lp)]

> I tried exporting to ps/eps and converting to pdf
> but the results are the same and/or the pictures
> get damaged.

How did you convert PS/EPS to PDF, and which viewer was used to verify the resulting PDF file?

(Possibly related to bug #168014 (comment #14) if the PDF file was opened in Inkscape - triggered by clipped paths with a pattern-fill)

[su_v (suv-lp)]

Quick test: after changing all paths which use a pattern to a solid fill and exporting to PDF, evince renders it instantly without any delays or hangs.

[pepe (sf-cbg)]

a) Debian unstable, inkscape 0.48.1 r9760 (the picture in the about dialog is real slow BTW)
b) evince 2.32, okular 0.12.5 (are there any relevant viewers not using poppler?)
c) attached

I used epstopdf to convert an exported eps to pdf. Same problem. I also tried to open the pdf in evince and then save to ps/pdf by "print to file". Images get corrupted when exporting or printing to ps and when printing to pdf, its still darn slow.

According to the bug you mention this is supposed to be fixed in my version.

[pepe (sf-cbg)]

I confirm that the modified svg works fine when exporting to pdf. Not quite the picture I wanted, though...

[su_v (suv-lp)]

Possibly same underlying issue as (or duplicate of)
- Bug #486259 “Custom stripe pattern breaks pdf export” and
- Bug #706294 “Pattern fills cause memory leak”

A bug report had been filed upstream based on bug #706294:
 <https://bugs.freedesktop.org/show_bug.cgi?id=33364>
(appears to affect the cairo backend of poppler (evince, inkscape), the splash backend (okular) seems not affected)

[su_v (suv-lp)]

> According to the bug you mention this is
> supposed to be fixed in my version.

If this comment refers to bug #168014 - no, that's not fixed in your version (it no longer occurs with the new cairo-renderer in Inkscape trunk i.e. in the unstable development branch of Inkscape), but only likely to occur when opening/importing the PDF in Inkscape - the SVG itself has clipped paths with pattern-fills, not paths filled with patterns which contain clipped paths.

[pepe (sf-cbg)]

Is there some kind of workaround available? Can I transform the pictures, flatten them somehow, without creating pixel graphics? It appears the issue is long known and fixes are incomplete..

[pepe (sf-cbg)]

So I can use the trunk version, re-import the cliparts and use them in my work?

[su_v (suv-lp)]

> So I can use the trunk version, re-import the cliparts and use them in my work?

See my original comment - PDF exported with trunk are the same, the problem is with poppler/evince, not Inkscape, as far as I can tell.

Inkscape trunk only no longer has issues when rendering paths which have pattern fills which use clip-paths in their pattern definition (AFAICT does not apply to the clipart used in your SVG file). That error can also be exposed when round-trip editing PDF/PS/EPS files in Inkscape (where images or patterns from the PDF file can get represented in SVG by such patterns which contain clip-paths). Sorry for bringing this up here - it is only marginally related (when I asked how you verified the PDF files converted from the exported PS/EPS files).

[su_v (suv-lp)]

<off-topic>
> Is there some kind of workaround available? Can I transform
> the pictures, flatten them somehow, without creating pixel
> graphics?

There is no simple command I'm aware of that one could click in Inkscape to auto-magically perform such a task - pattern fills can't be converted or flattened in Inkscape.
a) You could for example manually work on each of the pattern-filled objects and use (linear, radial) gradients instead of the bitmap-based fill patterns to create the shading effects (like is done e.g. for the bottom-most cloud).
b) Alternatively, you could convert each of the pattern fills into an object (menu 'Object > Pattern > Pattern to Objects'), and reposition/scale the bitmap image which was used as fill pattern to match the original image [1].
Since e.g. the server symbol is used repeatedly in the document, you could edit only one of them and replace the other ones with clones of the edited one.

[1] The original shading in the clipart is achieved by applying a bitmap as pattern fill to a rectangular path, then clipping a group (containing the pattern-filled path) with the outline of the actual shape. Since the clip-path for each of the shaded parts is applied to a parent group one can edit the clipped path(s) inside the group without releasing the clip:
- enter the (nested) clipped group(s) by double-clicking until you reach the group level of the pattern-filled path,
- select the path with the pattern fill and convert the pattern to objects (Shift+Alt+I)
- reposition the former pattern fill object (move the group with the bitmap image of the shading with the cursor keys until it is visible inside the clipped area)
- adjust its size if needed with the transformation arrows of the select tool
</off-topic>

[pepe (sf-cbg)]

Perfect, thanks a lot!

[su_v (suv-lp)]

Confirming in Inkscape for now - needs to be investigated by a dev familiar with cairo/poppler details (and able to use cairo-trace which still fails on osx) whether Inkscape's export of patterns does create "broken" PDFs or trigger a bug in the poppler-cairo backend of PDF viewers.

-> adding back 'exporting' tag.

[su_v (suv-lp)]

For further investigation: attaching a modified version of 'protocolstack.svgz' with edited clip-art objects to avoid the pattern fills (clipped grouped bitmaps instead of clipped paths with a bitmap-pattern fill): the generated PDF file (export drawing area) renders identical to Inkscape and without any delay in Evince 2.30.3.

[Beluga (buovjaga)]

Yeah Okular takes a while before showing it (tested with original).

Arch Linux 64-bit, KDE Plasma 5
Inkscape 0.92pre1 15054 (GTK3)