opaque radial gradients don't export to pdf correctly

[Adam Freidin]

Radial gradients that consist of only opaque (alpha = 255) colors export incorrectly.

I have attached an example of the bug. Document Viewer (ubuntu 9.10) shows the opaque gradient as the central color (flat shade), while inkscape re-imports it as the outer color, so the gradient is still getting exported in some fashion.

Both inkscape (export/reimport) and document viewer handle gradients with either (or both) colors with alpha = 254 correctly.

[Adam Freidin (adam-freidin)]

sorry, forgot to say:

$ inkscape --version
Inkscape 0.47pre4 r22446 (Oct 14 2009)

[su_v (suv-lp)]

1) Could you attach the missing linked bitmap in the upper left corner of the SVG document if it is important to reproduce and compare the result with different versions/platforms?

2) When I tried to export your attached file (as is) to PDF - Inkscape almost brought down my system (using all resources it could get) and I finally decided to force quit it (Inkscape 0.47+devel r9191 on OS X 10.5.8, Cairo 1.8.10)
Could you please attach the original SVG file you used to test the differing output depending on the alpha value for the radial gradient as well as the exported PDF file?

[Adam Freidin (adam-freidin)]

oops. Sorry. The small versions are from roundtrip
inkscape->pdf->inkscape, and they seem to not want to go around again.

I didn't realize that copy-as-bitmap/paste made a random file on my
computer. I'll get this all fixed.

              -Adam

On Sun, Mar 14, 2010 at 3:28 PM, ~suv <email address hidden> wrote:

> 1) Could you attach the missing linked bitmap in the upper left corner
> of the SVG document if it is important to reproduce and compare the
> result with different versions/platforms?
>
> 2) When I tried to export your attached file (as is) to PDF - Inkscape
> almost brought down my system (using all resources it could get) and I
> finally decided to force quit it (Inkscape 0.47+devel r9191 on OS X 10.5.8,
> Cairo 1.8.10)
> Could you please attach the original SVG file you used to test the
> differing output depending on the alpha value for the radial gradient as
> well as the exported PDF file?
>
> --
> opaque radial gradients don't export to pdf correctly
> https://bugs.launchpad.net/bugs/538749
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Inkscape: A Vector Drawing Tool: New
>
> Bug description:
> Radial gradients that consist of only opaque (alpha = 255) colors export
> incorrectly.
>
> I have attached an example of the bug. Document Viewer (ubuntu 9.10) shows
> the opaque gradient as the central color (flat shade), while inkscape
> re-imports it as the outer color, so the gradient is still getting exported
> in some fashion.
>
> Both inkscape (export/reimport) and document viewer handle gradients with
> either (or both) colors with alpha = 254 correctly.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/inkscape/+bug/538749/+subscribe
>

[Adam Freidin (adam-freidin)]

oops. Sorry.

In the zip file:

bug.svg (referencing, in the same folder, sample.png),
can be converted to pdf (also there, for reference).
the screenshot is from Document Viewer (evince?), ... whatever xdg-open does in Ubuntu 9.10.
the inkscape-pdf-inkscape.png comes from inkscape importing bug.pdf and exporting a png.

I've downloaded the source to both inkscape and cairo, and cairo has conditionals involving opacity,
whereas inkscape's code doesn't seem to care. So, do we push this into cairo's bug database or
run a workaround on our end?

P.S. the bug is still evident in trunk, "Inkscape 0.46+devel r22680 (Mar 14 2010)"

[su_v (suv-lp)]

> I've downloaded the source to both inkscape and cairo
which version of cairo - 1.8.10 or cairo-devel?

> P.S. the bug is still evident in trunk, "Inkscape 0.46+devel r22680 (Mar 14 2010)"
Inkscape has moved to bzr after the release of 0.47, current bzr trunk is at 0.47+devel r9191
<http://www.inkscape.org/archive.php?lang=en&year=2009&month=12>
<http://www.inkscape.org/bzr.php?lang=en>

[su_v (suv-lp)]

I'm not sure this is an issue with cairo-based export at all - looks more like a poppler issue to me (used for PDF import in Inkscape as well as by evince): compare the attached screenshot of the PDF as rendered with the default PDF viewer on OS X to your screenshot (of evince?).

[su_v (suv-lp)]

Unfortunately I can't verify with GhostScript 8.70 and 8.71 that the exported PDF file is ok: gs fails to render the PDF file - due to GhostScript issue 689150 – /rangecheck in run with x11alpha
<http://bugs.ghostscript.com/show_bug.cgi?id=689150>

Can someone test the PDF file with Adobe Acrobat?

[Adam Freidin (adam-freidin)]

Well, It can't be just a poppler issue, because the importing the pdf back into inkscape is also broken in a similar way.

Poppler is definately confused too, I can get different colors (or sometimes a combination of the two, but not in a radial gradient) by zooming in and out on the broken pdf.

[su_v (suv-lp)]

> It can't be just a poppler issue, because the importing
> the pdf back into inkscape is also broken in a similar way.

Inkscape uses poppler for PDF import.

[Adam Freidin (adam-freidin)]

More research:

It's a coordinate issue. The flat-shade re-import is a gradient with the center point and the focus point in weird places.

Also: The bug doesn't manifest if there's no stroke around the gradient. In the case of stroke v.s. no stroke, the difference between the resulting pdfs is only the /FlateDecode stream at the begining of the file, which I am having trouble digging into.

[su_v (suv-lp)]

Bug #514919 “PDF output displays differently on okular, acroread, evince, xpdf” seems to be the same issue.
<https://bugs.launchpad.net/inkscape/+bug/514919>

[su_v (suv-lp)]

With regard to the test files from the archive attached in comment #5:
- bug.svg
- bug.pdf (created with cairo 1.8.8)

1) Opening PDF file in evince (GNOME Document Viewer 2.30.3):
- Evince 2.30.3 with poppler 0.16.6, cairo 1.10.2
  renders the PDF file correctly

2) Opening PDF file in Inkscape (0.48.2, 0.48+devel r10325, r10626):
- Inkscape with poppler 1.12.4, cairo 1.8.10:
  thumbnail preview on import is correct
  on-canvas the first of the three gradients is positioned incorrectly
- Inkscape with poppler 0.16.6, cairo 1.10.2:
  thumbnail preview on import is correct
  on-canvas the first of the three gradients is positioned incorrectly

3) Saving the SVG file in Inkscape as PDF (0.48.2, 0.48+devel r10325, r10626):
- Inkscape with poppler 0.12.4, cairo 1.8.10:
  produces a PDF file which has the gradient displaced when opening
  the PDF in any Inkscape version
  (thumbnail preview on import is correct)
- Inkscape with poppler 0.16.6, cairo 1.10.2:
  produces a PDF file which has the gradient correctly positioned when
  opening the PDF file in any Inkscape version

Proposing to close as 'Invalid' in Inkscape -> it appears that the issue was fixed upstream (in poppler and/or cairo).

[su_v (suv-lp)]

Bug #411455 “Gradients exported to PDF do not work when using "Fit to page selection"” seems to be the same issue.
<https://bugs.launchpad.net/inkscape/+bug/411455>

[su_v (suv-lp)]

Caveat for testers:
PDF files created with cairo 1.10.x with opaque radial gradients fail to open in Adobe Reader.

This bug is fixed upstream in the latest cairo snapshot 1.11.2 -> see
Bug #681512 “Opaque radial gradients cause PDFs to fail to open in Adobe Reader”
<https://bugs.launchpad.net/inkscape/+bug/681512>

[su_v (suv-lp)]

> Well, It can't be just a poppler issue, because the importing
> the pdf back into inkscape is also broken in a similar way.

This part of the issue (position of the gradient in Inkscape) was finally fixed in r10680 (see attached screenshot comparing the file 'bug.pdf' from the archive with the test files (comment #5) in r10678 on the left to r10680 on the right).

Closing as 'Invalid' in Inkscape:
a) Evince (GNOME Document Viewer 2.30.3) as well as Inkscape display PDFs generated with later cairo versions just fine.
b) PDF import of the transformed gradient in Inkscape was fixed in trunk (tracked in bug #530895).

Please reopen if you don't agree and think this was done in error.