[Upstream] Exporting pdf from LibreOffice with smooth gradient displays striped in Evince, shows correctly in Adobe Reader

[diegoe]

Upstream URL:
https://gitlab.freedesktop.org/poppler/poppler/issues/626

1) lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

2) apt-cache policy evince
evince:
  Installed: 2.32.0-0ubuntu12.2
  Candidate: 2.32.0-0ubuntu12.2
  Version table:
 *** 2.32.0-0ubuntu12.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
        100 /var/lib/dpkg/status
     2.32.0-0ubuntu12 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

3) What is expected in Impress via the Terminal:

cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281555/+files/example.odp && loimpress -nologo example.odp

export the file with Gradient 1 inserted into the background to pdf ( https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281556/+files/example.pdf ), open the pdf with Evince and it looks as it does in both Impress and Adobe Reader.

4) What happens instead is Evince shows a striped gradient.

WORKAROUND: Open with chromium-browser or chrome built-in PDF reader (not Firefox).

Use Adobe Reader.

apt-cache policy acroread
acroread:
  Installed: 9.4.2-0natty1
  Candidate: 9.4.2-0natty1
  Version table:
 *** 9.4.2-0natty1 0
        500 http://archive.canonical.com/ubuntu/ natty/partner i386 Packages
        100 /var/lib/dpkg/status

[Chris Cheney (ccheney)]

Confirmed on upstream's 2.4.0~rc2

[nZain (patrick-stalph)]

Also affects current upstream version (OpenOffice.org 3.1.1, OOO310m19 Build:9420) in Ubuntu Karmic (9.10). Furthermore, this affects export to eps as well. Exporting to non-vector graphics format (jpeg, png, etc) does not show the stripes. Non-vector graphics formats are not an option for me, since the fonts are messed up, when those graphics are scaled.

However, I'm not sure where exactly the problem is:
- pdf/eps creation, thus somewhere in OOo or its dependencies
- pdf/eps viewer

The following viewers show the stripes: evince, xpdf, epdfview. Interestingly foxit does not show the stripes (maybe due to some aliasing?). There were problems with gradients in the backend of evince & co (poppler?), but this is fixed (gradients produced with LaTeX Beamer are fine).

[Robert Roth (evfool)]

I have checked on Maverick using OpenOffice 3.2.1, and it seems that the problem is not with the openoffice backend, because I have checked the pdf opening with Evince, XPdf and adobe reader 9 available in Software center. Only adobe reader renders it fine. See the screenshots attached for each application, and the test pdf to check for yourself.

[Robert Roth (evfool)]

Because of the screenshots attached above, I don't think the problem is with OpenOffice, as the doc displays correcly on windows and in adobe reader on linux too, the rendering issues appear only in xpdf and evince, therefore I am setting this as affecting xpdf and poppler too.

[Joe Harrington (joeharr)]

Very nice test!

However, I am told that Adobe readers are very "permissive" and accept/"do
the right thing" in some cases with buggy PDF or PS code. The lines appear
in printed versions of these documents.

I don't know anything about either PDF or PS, but can you or someone
actually look at the emitted PDF code to see how it is specifying
gradients? Someone in one of these many related bugs did that once and
isolated it to a problem in poppler, I think. This was a while ago, maybe
more than a year back.

--jh--

On Thu, Dec 9, 2010 at 1:24 AM, Robert Roth <email address hidden>wrote:

> Because of the screenshots attached above, I don't think the problem is
> with OpenOffice, as the doc displays correcly on windows and in adobe
> reader on linux too, the rendering issues appear only in xpdf and
> evince, therefore I am setting this as affecting xpdf and poppler too.
>
> ** Also affects: poppler
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (270726).
> https://bugs.launchpad.net/bugs/164233
>
> Title:
> [Upstream] [hardy] Exporting a background with gradient produces a stripey
> pdf
>

[Robert Roth (evfool)]

Foxit reader also displays the pdf as expected, so it is not an Adobe Reader-only feature.

[nZain (patrick-stalph)]

So, we're testing. (The attachment contains six files, three created with OpenOffice, three produced with Inkscape.)

1) If this is *not* an ooo bug, gradients produced with other programs should have the same issue: not the case. Create a gradient with inkscape, store as pdf - looks fine in all viewers. (attached: is.pdf)

2) Maybe inkscape produces the pdf differently? Not the case. Create a gradient in ooo, store as svg (attached: ooo.svg). Open with inkscape and you see a wierd gradient in inkscape (no fine stripes, but large blurry ones). Interestingly, the text stored from OOo is missing. Export as pdf (attached: ooo.svg-is.pdf) and you get the exact same stripes as directly exporting from ooo, but this time without text.

3) Lets do it the other way around. Create gradient with inkscape, store as svg (attached: is.svg). Open with OpenOffice, ohm... actually I get an empty (white) background and a large green block (the font in inkscape was green). The export to pdf reveals a little more, that is an inverted gradient plus the green block (attached: is.svg-ooo.pdf).

4) For the sake of completeness, I also included the original issue, that is, creating the gradient in OOo and exporting as pdf (attached: ooo.pdf).

Conclusion: There's a lot of stuff going wrong.
- OpenOffice produces wierd gradients (not only in PDF, but also SVG).
- OpenOffice can't open Inkscape produced SVG files properly... I should file another bug for this, actually I didn't expect it. But I don't have the time right now.
- Inkscape does not find/display the text stored in OOo (another bug? Oh my.)

[nZain (patrick-stalph)]

Oh, I forgot... I think Acrobat and Foxit display those files "correctly" due to some smoothing, anti-aliasing or whatever. Nice feature, but the print reveals the terror... which can be very costly, when you print a 140mm x 90mm colored poster for a conference and the responsible guys don't double-check your crappy pdf.

[Robert Roth (evfool)]

Thanks for the detailed tests.

See bug #138141 for the text not visible issue, caused by openoffice setting the fill and the stroke in the svg to none instead of black.
Than this is an OO.o issue indeed.

If evince and xpdf display it as the doc is printed, then I'll remove the Poppler from the affected project, as IMO the displayed doc should be as close to the printed one as possible.

As of the issue related to opening inkscape created SVGs - a new bug should be filed for that indeed, as that is a separate issue concerning the SVG import. The one reported here is related to exporting to SVG.

[nZain (patrick-stalph)]

As you said this, I double-checked and printed the first example pdf - that shows with stripes. It prints just fine without stripes on our laserprinter at the lab. So this may affect poppler as well. Sorry for the confusion :-(

[Joe Harrington (joeharr)]

I don't have time to chase it down at the moment but maybe you do, Chris. I recall reading some time ago that the problem is in the poppler PDF-writing library, which uses a broken algorithm to make the gradient out of a set of constant-color stripes whose edges are being rendered as white lines by some readers and not by others. Other PDF-writing programs that do not use poppler (from Win or Mac worlds) produce them differently. So the problem is in poppler, if I recall it all correctly.

--jh--

[Adrian Johnson (ajohnson-redneon)]

The PDF does not contain a gradient. It contains a series 2 point high filled rectangles designed to look like a gradient. Evince has trouble with white seams showing between adjacent fills due to antialiasing.

The best solution would be if openoffice used a PDF gradient. The bug where evince rendered gradients using lots of thin rectangles with visible seams was fixed a long time ago. Evince now uses cairo gradients and will render PDF linear gradients fine without any stripes.

[Tobin Davis (gruemaster)]

Following the steps above to create my own presentation slide in LibreOffice with a gradient background I was able to reproduce this. My system is running precise beta 1 (AMD64).

[Tobin Davis (gruemaster)]

I retested this on a theory (see 164233.tar.gz). Test1.pdf is from the steps above, and produces a chunky result as described. test2.pdf however was created using the print to file method of creating pdf files, which I believe is a completely different library, and it looks right (at least on this system).

This leads me to believe that the issue is in /usr/lib/libreoffice/program/libpdffilterlo.so or OpenOffice/LibreOffice.

[Tobin Davis (gruemaster)]

Oddly enough, acroread will read & display both versions (and all the other attachments) just fine, so both evince and libreoffice are problematic.

[Adrian Johnson (ajohnson-redneon)]

Test2.pdf is a postscript file, not pdf. So it will be rendered by ghostscript when viewed with evince.

The problem is caused by libreoffice. The "gradient" is actually a series of shaded rectangles. In fact the rectangles are not even correctly aligned. There is a tiny gap between each one. Cairo (used by evince) has a problem with showing lines between adjacent fills due to antialiasing. There is no easy way to fix this. And the small gaps between the rectangles caused by libreoffice will make the problem worse.

The best solution is for libreoffice to use PDF gradients to draw the shading.

[penalvch (penalvch)]

As per Evince upstream, the bug is in libcairo.

[penalvch (penalvch)]

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/evince/+bug/164233

1) lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04

2) apt-cache policy evince
evince:
  Installed: 3.3.90-0ubuntu3
  Candidate: 3.3.90-0ubuntu3
  Version table:
 *** 3.3.90-0ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status

3) What is expected in Impress via the Terminal:

cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/164233/+attachment/2281555/+files/example.odp && loimpress -nologo example.odp

export the file with Gradient 1 inserted into the background to pdf ( https://bugs.launchpad.net/ubuntu/+source/evince/+bug/164233/+attachment/2281556/+files/example.pdf ), open the pdf with Evince and it looks as it does in both Impress and Adobe Reader.

4) What happens instead is Evince shows a striped gradient.

WORKAROUND: Use Adobe Reader.

[James H. Cloos Jr. (cloos-jhcloos)]

The shadings are split into chunks; the chunks are rendered with blank
space between.

Another example (this is a type 7 shading, converted from ps by gs):

  http://jhcloos.com/PostScript/XYZsweep.pdf

[Albert Astals Cid (aacid)]

Both http://jhcloos.com/PostScript/XYZsweep.pdf and https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/164233/+attachment/2281555/+files/example.odp give 404 here

[James H. Cloos Jr. (cloos-jhcloos)]

> http://jhcloos.com/PostScript/XYZsweep.pdf 404[s]

D’Oh. I thought that I had pushed that out ages ago. It is there now.
As is the .ps version on which it is based.

Using the demos, the spacing is evident in the gtk demo (cairo master,
here) and in the qt4 demo when using Arthur with anti-aliased graphics.
Switching to splash or disabling graphics anti-aliasing avoids the spacing.

The rendering remains blocky, though. Only per-pixel sampling of the
shading would solve that issue.

On the cairo side, using cairo’s gradient api probably would help.

[penalvch (penalvch)]

Albert Astals Cid, sorry about the 404. This occurred because the downstream package changed, so the attachment URL changed too... :( Attachment is now at: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281555/+files/example.odp

[Joe Harrington (joeharr)]

Folks, we've gone round and round on this bug literally for *years*!
Is anyone reading who is close enough to the developers just to call
or email or skype someone who is familiar with the libreoffice code
and ask for a patch?

Many thanks if you can!

--jh--

On Thu, Mar 22, 2012 at 8:18 PM, Christopher M. Penalver
<email address hidden> wrote:
> ** Description changed:
>
>  1) lsb_release -rd
>  Description:  Ubuntu 11.04
>  Release:      11.04
>
>  2) apt-cache policy evince
>  evince:
>    Installed: 2.32.0-0ubuntu12.2
>    Candidate: 2.32.0-0ubuntu12.2
>    Version table:
>   *** 2.32.0-0ubuntu12.2 0
>          500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
>          100 /var/lib/dpkg/status
>       2.32.0-0ubuntu12 0
>          500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
>
>  3) What is expected in Impress via the Terminal:
>
>  cd ~/Desktop && wget
> - https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/164233/+attachment/2281555/+files/example.odp
> + https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281555/+files/example.odp
>  && loimpress -nologo example.odp
>
>  export the file with Gradient 1 inserted into the background to pdf (
>  https://bugs.launchpad.net/ubuntu/+source/evince/+bug/164233/+attachment/2281556/+files/example.pdf
>  ), open the pdf with Evince and it looks as it does in both Impress and
>  Adobe Reader.
>
>  4) What happens instead is Evince shows a striped gradient.
>
>  WORKAROUND: Use Adobe Reader.
>
>  apt-cache policy acroread
>  acroread:
>    Installed: 9.4.2-0natty1
>    Candidate: 9.4.2-0natty1
>    Version table:
>   *** 9.4.2-0natty1 0
>          500 http://archive.canonical.com/ubuntu/ natty/partner i386 Packages
>          100 /var/lib/dpkg/status
>
> ** Description changed:
>
>  1) lsb_release -rd
>  Description:  Ubuntu 11.04
>  Release:      11.04
>
>  2) apt-cache policy evince
>  evince:
>    Installed: 2.32.0-0ubuntu12.2
>    Candidate: 2.32.0-0ubuntu12.2
>    Version table:
>   *** 2.32.0-0ubuntu12.2 0
>          500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
>          100 /var/lib/dpkg/status
>       2.32.0-0ubuntu12 0
>          500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
>
>  3) What is expected in Impress via the Terminal:
>
>  cd ~/Desktop && wget
>  https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281555/+files/example.odp
>  && loimpress -nologo example.odp
>
>  export the file with Gradient 1 inserted into the background to pdf (
> - https://bugs.launchpad.net/ubuntu/+source/evince/+bug/164233/+attachment/2281556/+files/example.pdf
> + https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/164233/+attachment/2281556/+files/example.pdf
>  ), open the pdf with Evince and it looks as it does in both Impress and
>  Adobe Reader.
>
>  4) What happens instead is Evince shows a striped gradient.
>
>  WORKAROUND: Use Adobe Reader.
>
>  apt-cache policy acroread
>  acroread:
>    Installed: 9.4.2-0natty1
>    Candidate: 9.4.2-0natty1
>    Version table:
>   *** 9.4.2-0natty1 0
>          500 http://archive.canonical.com/ubuntu/ natty...

[Adrian Johnson (ajohnson-redneon)]

(In reply to comment #1)
> The shadings are split into chunks; the chunks are rendered with blank
> space between.
>
> Another example (this is a type 7 shading, converted from ps by gs):
>
> http://jhcloos.com/PostScript/XYZsweep.pdf

This is not quite the same as the LibreOffice PDF. The LibreOffice PDF is emulating a gradient by drawing series of rectangles. XYZsweep contains a native PDF gradient. The seams in the cairo rendering of XYZsweep have been fixed with the release of cairo 1.12 which supports Type 6/7 gradients.

XYZsweep.pdf is an interesting test case. Cairo (using cairo 1.12 and poppler master) renders this almost the same as acroread while splash renders it similar to ghostscript with a much larger pink area in the bottom right. I'm not sure which is correct. Printing the file as a PDF to my printer (I don't know who makes the PDF interpreter for Xerox printers) results in the same output as acroread. After printing the file to PS using acroread, ghostscript still renders it the same with the larger pink area but my printer (Adobe PS interpreter) gets it wrong with large blob of dark blue on the bottom right.

[James H. Cloos Jr. (cloos-jhcloos)]

> This is not quite the same as the LibreOffice PDF. The LibreOffice PDF is
> emulating a gradient by drawing series of rectangles.

Oh. I didn't look at it because the symtoms seemed to match those of a
native shading.

> XYZsweep contains a native PDF gradient.

Yes.

> The seams in the cairo rendering of XYZsweep have been
> fixed with the release of cairo 1.12 which supports Type 6/7 gradients.

I've been using git master for cairo and poppler for months (years?).

> XYZsweep.pdf is an interesting test case.

I wrote the postscript version to see what ghostscript would do after
the colour management features were added.

> Cairo (using cairo 1.12 and poppler master) renders this almost the
> same as acroread while splash renders it similar to ghostscript with a
> much larger pink area in the bottom right.

GS and poppler both use lcms2. When rendering to RGB both default to sRGB.

Here, acro's on-screen rendering looks like mupdf's, which does a simple
lab->srgb conversion.

But I get the same result from evince and poppler-glib-demo as I get
from splash and gs. (but with the white curves between the patches.)

> I'm not sure which is correct.

Neither do I.

> Printing the file as a PDF to my printer
> (I don't know who makes the PDF interpreter for Xerox printers)

Depends on the printer. Xerox licenses Adobe's for their more expensive
printers, but use someone elses for the less costly ones. If your
printer supports pantone directly (ie as /DeviceN named colours) then it
probably has adobe's ps3/pdf1.7 interpreter. Otherwise it probably has
the alternate ps3/pdf1.5.

> results in the same output as acroread.

> After printing the file to PS using acroread, ghostscript still
> renders it the same with the larger pink area but my printer (Adobe PS
> interpreter) gets it wrong with large blob of dark blue on the bottom
> right.

Interesting. If I set 'let the printer handle colors' in the advanced
dialog from acro's print dialog, gs generates the same rendering as it
does with the original pdf. If that is unset, it generates a subdued
rendering similar to acro and mupdf.

The first case creates a CIEBasedABC colour space in the ps, so that is
expected. The latter uses /DeviceCMYK (which is why gs renders it a bit
subdued as compared to /DeviceRGB).

The acro rendering probably is correct.

I’ll have to spend the toner and see what my printer does.

[Adrian Johnson (ajohnson-redneon)]

(In reply to comment #6)
> > The seams in the cairo rendering of XYZsweep have been
> > fixed with the release of cairo 1.12 which supports Type 6/7 gradients.
>
> I've been using git master for cairo and poppler for months (years?).

The fix to make poppler-cairo use cairo 1.12 mesh gradients was a few hours ago :)

> > Printing the file as a PDF to my printer
> > (I don't know who makes the PDF interpreter for Xerox printers)
>
> Depends on the printer. Xerox licenses Adobe's for their more expensive
> printers, but use someone elses for the less costly ones. If your
> printer supports pantone directly (ie as /DeviceN named colours) then it
> probably has adobe's ps3/pdf1.7 interpreter. Otherwise it probably has
> the alternate ps3/pdf1.5.

Mine is a Fuji Xerox CM305. It is the cheapest that supports PS. It definitely has Adobe PS3. It has the Adobe PS logo on the printer and demo pages. Telneting the printer and starting the executive shows the Adobe copyright notice. But I don't know any way of finding out what PDF interpreter it has.

[Adrian Johnson (ajohnson-redneon)]

Getting back on topic...

The problem of seams between adjacent fills is a well known limitation of cairo. There has been plenty written about it on the cairo list [1][2]. It is caused by the incremental antialiasing used by cairo. There is no simple fix. It is inherent in the design [3]. There have been various work arounds suggested (eg full scene antialiasing) but they are all slow and resource intensive.

I don't know how acroread makes it work. It might be something to do with keeping shape and opacity separate [4].

There is an experimental patch in bug 19760 where I tried fixing the problem by aligning fills to device pixels but in some cases this made the problem worse.

The best (and quicker) solution would be for LibreOffice to make use of native PDF gradients to draw gradients. There have been other reports of OpenOffice's faux gradients causing problems when printing [5] or with other viewers including acroread [6].

[1] http://lists.cairographics.org/archives/cairo/2005-November/005726.html
[2] http://lists.cairographics.org/archives/cairo/2006-March/006558.html
[3] http://lists.cairographics.org/archives/cairo/2008-January/012694.html
[4] http://lists.cairographics.org/archives/cairo/2006-April/006615.html
[5] http://www.oooforum.org/forum/viewtopic.phtml?t=60690
[6] https://issues.apache.org/ooo/show_bug.cgi?id=65970

[James H. Cloos Jr. (cloos-jhcloos)]

 The fix to make poppler-cairo use cairo 1.12 mesh gradients was a few hours ago :)

I fell asleep before posting again; after updating poppler with that
commit as HEAD the cairo rendering of type 7 and type 4 shadings is
nice and smooth.

[James H. Cloos Jr. (cloos-jhcloos)]

> Mine is a Fuji Xerox CM305. It is the cheapest that supports PS. It
> definitely has Adobe PS3. ... But I don't know any way of finding out
> what PDF interpreter it has.

The ad copy says “PCL6, PCL5, Adobe PostScript 3, FX-PDF”, which implies
that is it not Adobe’s.

Interesting.

The ad copy for what they sell in the States is quite different.
Everything I found here marketed by Xerox which had Adobe PS3 also
specified Adobe PDF1.7. But it looks like that has changed this year.
They don't claim *any* pdf support on the workcentre printer which
is similar to yours.

[Stan Schymanski (schymans)]

Thanks for the tip about Acroread. I also found another workaround. Printing to file using cups-pdf creates a file that shows smooth gradients in Evince.

[sae.area (saearea-test)]

I've tried the workaround with CUPS-PDF, but still have the lines. Running Ubuntu 12.04

[kitaets (chinaman)]

Gradients not only displayed striped, they are really become striped and they looks like semi-transparent if there is something behind. For example if a shape has a shadow the shadow becomes visible behind the shape.
I have exported Draw and Impress documents to PDF and checked them in:
- Evince.
- PDFedit
- online GoogleDocs viewer
It looks the striped/semi-transparend every time but looks Ok in Adobe Reader.
// I use LibO 3.5.6.2 in Ubuntu 12.04

[kitaets (chinaman)]

I checked Inkscape PDF and it looks great. As I see all of you have decided that this is Libreoffice bug. Yesterday I have posted a bugreport to bugs.freedesktop.org than I went here and now I'm going back there.
You can participate in discussion - Bug 55698 at bugs.freedesktop.org.
CU

[penalvch (penalvch)]

Reproducible in latest release available from Ubuntu (libcairo 1.13.0~20140204-0ubuntu1). As well, another WORKAROUND is to open this in chromium-browser or chrome via built-in PDF viewer (not Firefox).