Created attachment 515531 [details] cup-pdf doc with black placeholders instead images Description of problem: Vanilla F-15 Lxde fresh install, cups-pdf installed from the repo. When I print to pdf a web page, the images display as black placeholders. I never had a single issue on the same hardware, on F-13/F-14 using cups-pdf. No change and no particular setting, but to redirect the output directory in /home/cups-pdf editing the /etc/cups/cups-pdf.conf file. and to create a printer. Version-Release number of selected component (if applicable): cups-pdf 2.5.1 How reproducible: always Steps to Reproduce: 1. install cups-pdf 2. create a printer 3. print a web page with images Actual results: black placeholders display instead of the images Additional info: Print to file (.pdf) option correctly displays the images on the page. Web page test : http://ankisrs.net/docs/StudyOptions.html see attachments -Study_Options_cups_no_image.pdf: page printed using cups-pdf without images -Study_Options_print_to_file.pdf: page printed using print to file with images
Created attachment 515532 [details] print_to_file pdf file with images correctly displayed
Bug reproduced under Gnome3 standard installation. No link with LXDE.
Created attachment 515578 [details] cups spool file File generated by cups (postscript), transmitted by cups-pdf to ghostscript
Seems to be a ghostscript issue. cups-pdf generate the following command: /usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dSAFER \ -sDEVICE=pdfwrite -sOutputFile="/home/remi/Desktop/Study_Options.pdf" \ -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false \ -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite \ -f /var/spool/cups-pdf/SPOOL/cups2pdf-6935 The input file is OK (with image) The ouput file is KO (with black square) So I reaffect the bug to ghostscript component to get gs maintainer feedback.
Fixing bug status. VERIFIED means that the *fix* has been tested and verified...
Created attachment 516235 [details] Display a gray erea on a page 8, using print to file PDF Could you tell me if this is related to the bug? I have printed a web page using the print to file > PDF. The print-screen images of the web page appear on the PDF (They display black placeholders when I use cups-pdf), however, there is an additional grey square area on a non-image area. PDF dated from 08/02/2011 10:33 AM (Fedora 15) - page 8 displaying a gray square area on a no-image area. The same page printed months earlier: PDF dated from 03/07/2011 06:17 PM (Fedora 14) page 8 - white area correctly reproduced Thank you
Created attachment 516236 [details] Same PDF printed months earlier - page 8 renders correctly the white area
Still has the same behaviour in ghostscript-9.04-1.fc15.
Installed Packages Name : ghostscript Arch : i686 Version : 9.02 Release : 1.fc15 is ghostscript-9.04-1.fc15 in test-update repository?
Yes.
Created attachment 518780 [details] pdf-print w/ghostscript-9.04-2.fc15 su -c 'yum --enablerepo=updates-testing update ghostscript-9.04-2.fc15' did not fix the problem on my end. The enclosure is the same web page I've printed to pdf, for testing purpose. gs-9.04-2.fc15 outputs even more black & gray portion on the page than the previous build (sorry, if this is vague).
Yes, when I tested it I saw that it did not fix the problem (comment #8).
According to cups-pdf upstream (on another distro): > I just tested your file with GS and got the following results: > GS 8.62: only black boxes > GS 9.00: only black boxes So, this issue seems not a regression in latest GS, but an issue with postscript file generated by latest cups that ghostscript couldn't parse properly.
CUPS doesn't generate PostScript; it only modifies PostScript (with pstops). Poppler generates the PostScript from PDF input.
I am not sure if it is connected with this bug (black placeholders instead of images), but after printing a web page to PDF using cup-pdf, and opening the file in a pdf reader (Evince or ePDFViewer) the text in the pdf file can not be selected (e.g. to copy and past).
(In reply to comment #15) > I am not sure if it is connected with this bug (black placeholders instead of > images), but after printing a web page to PDF using cup-pdf, and opening the > file in a pdf reader (Evince or ePDFViewer) the text in the pdf file can not be > selected (e.g. to copy and past). Sounds like a separate issue.
Here's completely different way to reproduce this: 1) Print to PDF with firefox directly (PDF file works) 2) convert PDF to PS with pdftops (PS file works) 3) convert PS to PDF with ps2pdf (images are black boxes) If I print to PS with firefox directly, ps2pdf works fine. Also, a "ps2pdf 1.pdf 2.pdf" where 1.pdf is the PDF generated in step (1) works fine. Note, that ghostscript render the PS file generated in step (2) just fine. ghostscript also renders the PDF file generated in step (3) without any black boxes. (Yes, that right: the file which has black boxes in both acroread and evince has nice images, when being rendered by ghostscript itself).
Same bug occurring in Ubuntu/Kubuntu, https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/817049 . From that, the upstream bug for comment #4 is http://bugs.ghostscript.com/show_bug.cgi?id=692380 , resolved invalid (they claim ghostscript produces valid PDF, but some PDF interpreters including Adobe Reader are buggy). Regarding comment #14, there's a recent fix to Poppler's pdftops in https://bugs.freedesktop.org/show_bug.cgi?id=40076 "One problem with using Type 3 fonts for PDF tiling patterns is if the PS is converted back to PDF, some PDF viewers (including acroead) do not display the patterns." Since https://bugzilla.mozilla.org/show_bug.cgi?id=462872 (Firefox 5 and later?), Firefox and SeaMonkey send PDF jobs to CUPS, and these PDF spool files preview fine in all PDF interpreters I've tried. So why does CUPS convert this to ps then cups-pdf converts back into PDF? Seems like wasted work (and a separate bug). Hope this helps.
(In reply to comment #18) > Since https://bugzilla.mozilla.org/show_bug.cgi?id=462872 (Firefox 5 and > later?), Firefox and SeaMonkey send PDF jobs to CUPS, and these PDF spool files > preview fine in all PDF interpreters I've tried. So why does CUPS convert this > to ps then cups-pdf converts back into PDF? Seems like wasted work (and a > separate bug). It's because the CUPS job workflow is based around PostScript -- it needs jobs to be PostScript in order to apply job options and PPD options. There is a set of tools for a CUPS PDF workflow but I've been waiting until it goes upstream before we start shipping it.
Created attachment 527156 [details] broken print-screens on pages Hi, I have seen a cup-pdf update recently. I was hoping the bug would have been fixed. Will the print-to-pdf feature remain broken along the F-15 life? Thanks.
whoever who fixed this, thank you. I printed a few web pages with print-screens this morning. There is no more black box placeholders and the pictures show fine on the PDF pages.
nomnex: what does 'rpm -q ghostscript' say, so we can be sure which version contains the fix?
[mt@nh28d ~]$ rpm -q ghostscript ghostscript-9.04-3.fc15.i686
Thanks, great to know it's fixed now. https://admin.fedoraproject.org/updates/FEDORA-2011-10730