Pdf import displaces transparent gradients in pdf created with cairo > 1.11.4

Migrated from https://bugs.launchpad.net/inkscape/+bug/1078430 (a lot of copy paste but proofread and retested on my current system, did not test across different versions of cairo and their exports)

Summary:

  • Inkscape incorrectly converts transparent gradients of PDFs to SVG (created by Inkscape export, cairo >= 1.11.4, saving as pdf or printing to pdf via GTK+ print dialog)

Steps to reproduce:

  • open Inkscape
  • open this svg or create a rectangle and give it a gradient (will be #0000ffff to #0000ff00 by default)
  • save as pdf (1.4 or 1.5, default values)
  • open created pdf in Inkscape (default internal import)

What happened?

  • The gradient fills are displaced and partially clipped off
  • if poppler/cairo import used, different error occurs (see #3282 (moved)).

What should have happened?

  • The gradient fills in original SVG and opened PDF look identical (or at least very similar)

Pdfs affected

Affects newer versions of cairo
  • problematic pdfs created (by su_v) with cairo 1.12.4, 1.12.6 and 1.12.8 on OS X 10.7.4 (64bit) with GTK+/Quartz builds of Inkscape 0.48.3.1 and Inkscape 0.48+devel r11871.
  • unproblematic pdfs created (by su_v) with cairo (all <= 1.12.2) 1.8.8, 1.8.10 and 1.10.2 on all official Mac OS X Inkscape packages >= 0.47 (in 2012-11-13)
  • unproblematic pdfs created (by su_v) with cairo 1.10.2 (X11), 1.11.4 (Quartz) with local builds on Mac OS X 10.5.8 (32bit)
  • scaled rsvg-convert pdfs (see doesn't affect section)
pdf rendered in pdf viewers Problematic pdf (created with cairo 1.12.8)
  • crashed/segfaulted xpdf 3.03 on Ubuntu (does not segfault 3.04-7 on Linux Mint 19.1).
  • rendered with solid fill colors instead of gradient fills on Ghostscript 9.05 on OS X
  • rendered normally on Evince 2.30.3 (OS X), 3.6.0 (Ubuntu 12.10), Xpdf 3.02 (OS X), Ghostscript 9.06 (Ubuntu 12.10) and Apple's Preview.app (OS X)
Doesn't affect
  • pdfs created with libcairo 1.11.4 or older
    • unproblematic pdfs created (by su_v) with cairo 1.12.2 (X11) with local builds on OS X 10.7.4 (64bit)
    • unproblematic pdfs created (by su_v) with cairo 1.12.2 on a Ubuntu 12.10 x64 VM
  • fully opaque gradients, but these imports in a completely different way (transparent gradients are separated into opaque gradient and a mask with a transparency gradient)
  • librsvg 2.36.4 (cairo 1.12.8) export (still imported wrong on poppler/cairo import)
    • unless rsvg-convert scales the pdf to match the page size in Inkscape (in which case, internal import has same results). E.g rsvg-convert --format=pdf --zoom=0.8 --output=04831-1-cairo-1_12_8-librsvg-2_36_4-zoom_0.8.pdf 04831-1.svg, which produced 04831-1-cairo-1_12_8-librsvg-2_36_4-zoom_0.8.pdf

I can confirm that it doesn't affect pdfs exported by the 0.48.5-1 package (7z archive for Windows)

Example files

older file comparison comparison on old and new
1078430-screenshot-comparing-PDF-cairo-versions-in-r11871-osx 1078430-screenshot-comparing-old-and-new-exports

Version info from su_v on launchpad

Reproduced on Mac OS X 10.5.8 (32bit), OS X 10.7.4 (64bit) and Ubuntu 12.10 (64bit, VM) with:

  • Inkscape stable (0.47-0.48.3.1, various cairo and poppler versions)
  • Inkscape trunk r11871 (default PDF input extension) [*]
  • Inkscape trunk r11871 (experimental PDF via poppler-cairo input extension)
  • PDF -> SVG using pdftocairo (from poppler 0.20.4, 0.20.5) [*] poppler versions don't seem to affect the result (same import with poppler 0.16.6, 0.16.7, 0.18.4, 0.20.4 and 0.20.5)

Version Info (me and others on launchpad)

  • Reproduced Inkscape 1.1-dev (838ae0f22d, 2020-07-14, custom) Linux Mint 19.1, libcairo2 1.15.10-2ubuntu0.1
  • Reproduced Inkscape 0.92.5 (6c0c36ef5a, 2020-05-15) Linux Mint 19.1, libcairo2 1.15.10-2ubuntu0.1
  • Reproduced 0.48.5-1 r10040 x32 7z archive on Windows 10 x64 (though it exported a pdf that did not have issues
Some more replication info I'm unclear what was tested (is this pdf exports, or imports). If it includes imports, it may conflict against my tests in 0.48.5-1 . Important to know if it conflicts with my tests, so included it
  • Reproduced on Windows XP, Inkscape trunk revision 11871, cairo 1.12.8 (local test).
  • Not reproduced with cairo 1.11.2.

This is useful, but not too relevant to this report (which focuses on internal import, which corresponds to import with cairo) Tested with Inkscape 0.91 r13725 on Kubuntu.

Import with cairo:

  • 04831-1-cairo-1_12_8-04831.pdf : not displaced but partially clipped off.
  • 04831-1-cairo-1_12_8-librsvg-2_36_4.pdf : not displaced, not clipped off (correct).
  • 04831-1-cairo-1_12_8-librsvg-2_36_4-zoom_0.8.pdf : not displaced but partially clipped off.
  • 04831-1-cairo-1_12_8-r11871.pdf : not displaced but partially clipped off.

Import with poppler:

  • 04831-1-cairo-1_12_8-04831.pdf : not clipped off but displaced and blue gradient not stretched (=circle).
  • 04831-1-cairo-1_12_8-r11871.pdf : not clipped off but displaced and blue gradient not stretched (=circle).
  • 04831-1-cairo-1_12_8-librsvg-2_36_4.pdf : not displaced, not clipped off but blue gradient not stretched (=circle).
  • 04831-1-cairo-1_12_8-librsvg-2_36_4-zoom_0.8.pdf : not clipped off but displaced and blue gradient not stretched (=circle).
Edited by Nathan Lee
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information