Bug 692380

Summary:	When converting PostScript to PDF, images appear as black boxes
Product:	Ghostscript	Reporter:	Till Kamppeter <till.kamppeter>
Component:	PDF Writer	Assignee:	Ken Sharp <ken.sharp>
Status:	RESOLVED INVALID
Severity:	normal	CC:	info, jackie.rosen
Priority:	P4
Version:	master
Hardware:	PC
OS:	Linux
Customer:		Word Size:	---
Attachments:	z.ps - The file whose images get turned to black boxes a.pdf - The output file as I get it

Description Till Kamppeter 2011-07-27 17:18:30 UTC

Created attachment 7720 [details]
z.ps - The file whose images get turned to black boxes

See

https://bugs.launchpad.net/bugs/817049

The user has attached a PostScript file (generated by Poppler, attached) and if he converts this PostScript file to PDF with this command line

gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile=a.pdf -f z.ps

a.pdf has black boxes instead of the images.

The user has GS 9.01 and I can reproduce it with 9.04 (I think the snapshot is from July 15).

Comment 1 Till Kamppeter 2011-07-27 17:20:28 UTC

Created attachment 7721 [details]
a.pdf - The output file as I get it

Comment 2 Ken Sharp 2011-07-29 08:19:04 UTC

Downgrading severity, this has apparently been a problem for a long time, is not a regression and does not affect a commercial customer.

Comment 3 Ken Sharp 2011-07-29 13:30:54 UTC

(In reply to comment #2)
> Downgrading severity, this has apparently been a problem for a long time, is
> not a regression and does not affect a commercial customer.

This appears to be an Acrobat bug. Ghostscript, Jaws and the Apple PDF viewer all display the resulting PDF correctly. MuPDF, like Acrobat, displays a black rectangle but this is a known limitation of MuPDF which, in its current version, does not handle Type 3 font glyphs which use colour.

It seems Acrobat suffers the same limitation at least for glyphs using colour images.

It is possible that there is a pdfwrite bug here, but 3 PDF interpreters with no common heritage all give the same correct answer, Acrobat is odd man out, so I think its an Acrobat bug

Comment 4 Till Kamppeter 2011-07-29 14:02:23 UTC

The Poppler-based (AFAIK) evince also shows the black boxes, whereas (strangely enough) xpdf displays the file correctly.

Comment 5 skierpage 2011-08-31 23:27:26 UTC

Some more information for others having this problem...

As https://bugs.launchpad.net/bugs/817049 and https://bugzilla.redhat.com/show_bug.cgi?id=726090 and my report https://bugzilla.mozilla.org/show_bug.cgi?id=680639 all remark, printing from Linux Firefox and SeaMonkey to cups-pdf also triggers this bug for some people. Instead just File > Print > Print to File as PDF.

Firefox+Cairo creates a PDF 1.5 file (that previews fine in all PDF interpreters I've tried), then cups/cups-pdf transforms this to PostScript and then back into PDF 1.4.  (Seems a lot of work for nothing, I will look for a cups bug.) So another workaround is to hold the print job, look in /var/spool/cups/ (as root) for the input PDF file, and just use that.

The problematic PDFs have black images in Linux Inkscape 0.48.1 as well as in Adobe Reader (9.4.2 for Linux, Reader X for Windows). They preview OK in Okular and Windows' Foxit Reader.