|Summary:||Exporting pdf from LibreOffice with smooth gradient displays striped in Evince, shows correctly in Adobe Reader|
|Product:||poppler||Reporter:||Christopher M. Penalver <christopher.m.penalver>|
|Component:||cairo backend||Assignee:||poppler-bugs <poppler-bugs>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
Description Christopher M. Penalver 2012-03-22 04:17:07 UTC
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.
Comment 1 James Cloos 2012-03-22 07:53:45 UTC
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
Comment 2 Albert Astals Cid 2012-03-22 12:40:00 UTC
Comment 3 James Cloos 2012-03-22 15:11:15 UTC
> 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.
Comment 4 Christopher M. Penalver 2012-03-22 17:19:10 UTC
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
Comment 5 Adrian Johnson 2012-03-23 15:41:08 UTC
(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.
Comment 6 James Cloos 2012-03-23 17:17:42 UTC
> 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.
Comment 7 Adrian Johnson 2012-03-23 21:18:59 UTC
(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.
Comment 8 Adrian Johnson 2012-03-23 21:44:57 UTC
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 . It is caused by the incremental antialiasing used by cairo. There is no simple fix. It is inherent in the design . 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 . 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  or with other viewers including acroread .  http://lists.cairographics.org/archives/cairo/2005-November/005726.html  http://lists.cairographics.org/archives/cairo/2006-March/006558.html  http://lists.cairographics.org/archives/cairo/2008-January/012694.html  http://lists.cairographics.org/archives/cairo/2006-April/006615.html  http://www.oooforum.org/forum/viewtopic.phtml?t=60690  https://issues.apache.org/ooo/show_bug.cgi?id=65970
Comment 9 James Cloos 2012-03-24 09:40:05 UTC
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.
Comment 10 James Cloos 2012-03-24 10:35:12 UTC
> 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.
Comment 11 Stan 2012-04-19 13:26:59 UTC
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.
Comment 12 Christopher M. Penalver 2014-12-11 18:40:15 UTC
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).
Comment 13 GitLab Migration User 2018-08-21 11:19:51 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/626.