Happens with cairo/pixman from git, too.

This bug is easy to reproduce with lots of PDF files, usually ones with images.  I can print the same pdf from OS/X with no problems.

The attachment is a PDF file, probably because CUPS has switched to using PDF as the printing format. Your version of evince may be printing as PDF when printing to a CUPS printer. If it is printing as PS, CUPS will convert it to PDF before passing through its internal filters. It is only at the end of the filter chain that it is converted to PS or whatever format is required for printing.

You will need to do some further debugging to narrow down the cause. There are too many applications involved here (evince, poppler, cairo, CUPS) to be able to say it is a cairo bug.

Some things you can try:

- print to PDF from evince then print the file with lpr
- print to PS from evince then print with lpr and lpr -o raw (bypasses CUPS filtering)
- print from other applications to PS then print the PS with lpr -o raw. If it works attach the PS output here.

Ugh, thanks for the explanation.  I filed it on cairo because I had discussed it with cworth in person a while back, and he said "sounds like a cairo bug!"


evince print to file ps, lpr -o raw output.ps: works, although has a separate rendering bug

lpr original_file.pdf: works

evince print to file PDF, lpr output.pdf: printer stalls on page 4.

> evince print to file ps, lpr -o raw output.ps: works, although has a separate
> rendering bug

The cairo generated PS works but there is a bug in either poppler or cairo. Does the PS file render correctly with evince or gv?

> lpr original_file.pdf: works

Using poppler to generate the PS from the original PDF works.

> evince print to file PDF, lpr output.pdf: printer stalls on page 4.

Using poppler to generate PS from a poppler/cairo generated PDF does not work. If this PDF renders fine with evince/gv/acroread it points to a problem in poppler. In this case I can see that poppler is using a very different method of embedding images in PS compared with pdftops original.pdf. I have know idea why it is doing this. The first step to debugging it would be to find/create a simpler test case. If you can use something like eog/inkscape/openoffice to create a PDF containing a single image that triggers the bug it would a lot be easier to work with.

(In reply to comment #4)
> The cairo generated PS works but there is a bug in either poppler or cairo.
> Does the PS file render correctly with evince or gv?

No.

> > lpr original_file.pdf: works
> 
> Using poppler to generate the PS from the original PDF works.

This also exhibits the rendering problem above.

> > evince print to file PDF, lpr output.pdf: printer stalls on page 4.
> 
> Using poppler to generate PS from a poppler/cairo generated PDF does not work.
> If this PDF renders fine with evince/gv/acroread it points to a problem in
> poppler. In this case I can see that poppler is using a very different method
> of embedding images in PS compared with pdftops original.pdf. I have know idea
> why it is doing this. The first step to debugging it would be to find/create a
> simpler test case. If you can use something like eog/inkscape/openoffice to
> create a PDF containing a single image that triggers the bug it would a lot be
> easier to work with.

Will do this tomorrow.

-- 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/cairo/cairo/issues/203.