Closed
Bug 680639
Opened 14 years ago
Closed 14 years ago
images in cups-pdf output appear black in most PDF viewers
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: info, Unassigned)
Details
Attachments
(1 file)
15.00 KB,
application/octet-stream
|
Details |
I'm running Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110806 Firefox/6.0 SeaMonkey/2.3 on Kubuntu 11.04.
I print to PDF and the Generic CUPS-PDF printer driver creates a PDF file. In Adobe Reader 9.4.2 for Linux, Adobe Reader X for Windows, and Inkscape's PDF preview in its Open Dialog, the images appear completely black! This happens printing SeaMonkey mail messages with images, FedEx ship labels in the browser, and a tiny sample in Composer. What's odd is the same PDFs all preview fine in the Okular PDF preview program.
I have attached the PDF resulting from printing my simple Composer document to PDF. Try previewing it in a Linux PDF previewer (Okular, Evince, etc.), then compare with Adobe Reader. I compared the Mozilla PDF with a similar document printed to PDF from LibreOffice Writer; the latter has an ImageC resource in its ProcSet, and the former has image /Width 60 even though it's 59 pixels wide. Hmmm.
https://support.mozilla.com/en-US/questions/845440 has similar reports of Linux users getting black images from PDF output in Firefox 5.
I printed to PDF from Firefox Nightly, Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110818 Firefox/9.0a1, and got more or less the same PDF output and a black image in that as well. I don't know if I should change the bug version to 9 Branch or Trunk.
Comment 2•14 years ago
|
||
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110828 Firefox/9.0a1
Works For me on the latest nightly on Ubuntu 11.04. The Pdf file was displayed correctly both in Okular and in Adobe.
1. Install cups.pdf.
2. Print a page (with images) from Firefox.
3. Open the resulted files both in Adobe and Okular.
No black images were displayed. Everything worked fine for me.
Skyierpage, have you tried to start with a clean profile and see what happens?
Is there any extra information that you have and feel it would help to reproduce?
(In reply to Virgil Dicu [QA] from comment #2)
Thanks for trying to reproduce!
> 1. Install cups.pdf.
I assume you mean "cups-pdf". I'm running cups version 1.4.6-5ubuntu1.3 and cups-pdf version 2.5.1-3~natty , I think those are the default package versions for Kubuntu 11.04.
> Skyierpage, have you tried to start with a clean profile and see what
> happens?
Yes, the bug still occurs in Firefox nightly.
> Is there any extra information that you have and feel it would help to
> reproduce?
I could provide all kind of information, I wonder what's different in our systems? I think Mozilla on Linux prints by making calls to the Cairo graphics library when it is attached to a PostScript "surface", and Cairo produces PostScript output. Then CUPS uses ghostscript (I have gs version 9.01) to decode this and then its cups-pdf backend produces a PDF file. That's a lot of pieces to go wrong :-) ! I guess the next thing for me to do is to see if the PostScript stream produced by Mozilla is garbled, but I'm not sure how to capture this (a CUPS setting? a Mozilla debug flag?).
I put up a simple test HTML page, http://www.skierpage.com/bugs/print_test2.html that when I print has black for the image in Adobe Reader. If you know how to grab the PS maybe you could tell me how, attach the PS your system generates for this web page, and I can compare it with what mine does.
I printed again, but in File > Print > PDF > Job set Print Document to "On hold". I found a spooled file in
/var/spool/cups/d00070-001
This is a %PDF-1.5 file (File > Properties > PDF Producer is "cairo 1.9.5"), and it previews OK in Adobe Reader and Inkscape! It's only when I release the job and let it run that CUPS/Ghostscript/cups-pdf strangely transforms and downgrades this into a %PDF-1.4 file (File > Properties > PDF Producer is "GPL Ghostscript 9.01") in ~/PDF, and it's this transformed PDF that previews with black images. Although it's interesting that Mozilla's Cairo rendering for print can trigger this glitch, I doubt it's Mozilla's fault, so I'm resolving invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
The Firefox workaround is instead of choosing File > Print > PDF (i.e. a cups "printer" that just makes PDF files), choose File > Print > Print to file > Output format (x) PDF (i.e. Firefox makes the PDF file itself).
The black boxes arise because when the CUPS print system turns the PDF into PostScript, and then cups-pdf uses Ghostscript to turn PS back into PDF, it generates PDF that some PDF viewers don't like. The Ghostscript team don't consider this a bug, http://bugs.ghostscript.com/show_bug.cgi?id=692380
The reason for the wasted PDF > PostScript > PDF effort within CUPS is "CUPS job workflow is based around PostScript". Linux distributions are considering changing this, e.g. https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820 , but you lose some Ghostscript features.
Opaque images:
I don't think the problem is with Firefox. I've had the same problem with cups-pdf and printers in general.
I get an opaque, black background when I print an HTML document containing an RGB image. If you convert the three channel RGB image to a four channel RGBA image, reload the HTML document and it prints fine. The fourth "alpah" channel is used for opacity. I've had do this using gimp: http://gimp.org however I imagine you can do this with many graphics applications.
* open the image in gimp
* Select the Colors drop-down menu
* Select Color to Alpha . . .
* Save the image
* Reload the document in Firefox, be certain to refresh the cache
* The RGBA image included in the HTML document should now print correctly.
If not, check the alpha channel. The alpha channel can be set to shades of grey as well as b/w.
Paul
FWIW I can't reproduce this with Firefox Nightly 50.0a1 printing on Kubuntu 16.04, images look fine at all stages. I think CUPS now outputs PDF directly, so the PS -> Ghostscript -> PDF step is gone; plus all the software got better :-)
Resolution: INVALID → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•