Version: 0.5.5 (using KDE 3.5.5 "release 45.2" , openSUSE 10.2) Compiler: Target: i586-suse-linux OS: Linux (i686) release 2.6.18.8-0.1-default Printing via CUPS fails if * the document contains large images AND * the "reverse pages" option in the print-dialog is selected. Acroread, on the other hand, has no problems with it. (My printer is a Samsung ML-1610, but - as acroread works fine - that should not be the problem)
(Reassigning to kdeprint, as it's more a matter of the KDE printing system.)
(Forgot to say that this was originally reported as KPDF bug.)
Clemens, please provide a link to a testcase PDF. Also, please be more specific: * how "large" exactly are the images? * how many pages does the PDF have? * how big is the PDF file size? * what specific failure when printing do you see? Most likely this is not a KDEPrint bug... What KDEPrint does: ------------------- What happens when you select "reverse order" in KDEPrint is this: * KDEPrint will send the PostScript printfile *unchanged* to CUPS * on its commandline interface to CUPS, KDEPrint will send a "-o outputorder=reverse" parameter It will then be CUPS' job to reverse the page order when printing. This operation is possibly quite expensive on RAM and CPU. (And the CUPS print server may be a remote computer, not your own one...) What Acrobat Reader does: ------------------------- When you select reverse print order in acroread, it is this application that itself creates the PostScript in reverse page ordering. CUPS will then have to do no other processing for this aspect of the job. (It does not even know about the reversed page order). You can verify this by * "print to file" from acroread; * opening the created PS file in any PS viewer (kpdf, gv, gs, kghostview, gsview) Can you verify if CUPS is able to do the reversing for that job? Do this: * Create a PostScript file [use the "Print to File (PostScript)" printer]. * Print this file from the commandline specifying the reverse print order: lp -d <printername> -o outputorder=reverse /path/to/PSfile.ps If this also fails, it is not at all a problem of KDEPrint. If it fails, set "LogLevel" in cupsd.conf to "debug" and investigate what CUPS writes into its "error_log" when you print it (located in /var/log/cups/). Your most likely fix will be to increase the parameter RIPCache 8m in the cupsd.conf of your CUPS server to a higher value. Try something like RIPCache 100m if you can afford to spend 100MByte of RAM for CUPS job processing (100 MByte will not be used by CUPS permanently -- it merely defines the max. value CUPS will assign to individual filter processes while printing). -------------------- Setting timeout for this bug to April 15th. (If we don't see additional feedback within 4 weeks, we'll close this bug).
KDEPrint is obsolete, unmaintained and will never be revived. Closing all open bugs.