[Kde-print-devel] [Bug 143220] pdf printing with large images fails for reverse pages option

[Kurt Pfeifle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=143220         




------- Additional Comments From pfeifle kde org  2007-03-22 20:24 -------
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).