Bug 47706

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

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

> 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.

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

(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.

> 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.

(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.

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

 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.

> 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.

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.

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).

-- 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.