[cups] PDF workflow with old server?

Helge Blischke helgeblischke at web.de
Wed Apr 15 04:07:57 PDT 2015


Johan,

to see what really happens, please do a test print on one of your clients
which exhibit the issue under the conditions that on both the client and the server
the debug level is set to debug (by „cupsctl —debug-logging“) and post 
the respective portions of the error_log from both machines (you can mail these
to me off the list to „helgeblischke at web dot de“ (because the list handler
strips off attachments).
I suspect that the issue is a matter of the filters involved, so I need to know
which filters are actually called.

Helge

> Am 15.04.2015 um 11:41 schrieb Johan Bengtsson <elijah at chalmers.se>:
> 
> Hi,
> 
> We have a server running cups 1.4.6 and Linux clients running 1.7.5.
> 
> Client config:
> [elijah at upsilon ~]$ cat  /etc/cups/client.conf
> ServerName print.chalmers.se
> 
> This has led to very slow printing from Linux clients, with print jobs taking
> very long time or hanging, blank pages etc.
> I guess the problem must be that the Linux clients are now outputting pdf
> while the server is still running a ps-based workflow.
> We have approx. 500 postscript-enabled network printers
> and we think that most of them should be able to handle pdf as well.
> 
> We are not so keen on upgrading the server right now, so we've tried some
> workarounds. We thought that if only we could run the pdftopdf filter
> from a current cups version everything would be ok, but maybe we're mistaken?
> We set up another server with cups-filters-1.0.35-15.el7_0.1.x86_64 installed.
> Then we ran pdftopdf over ssh from that server. This results in fast printouts
> but option handling like tray selection is ignored.
> 
> What filters are needed for a pure pdf workflow? I thought only pdftopdf was
> needed, but when I look at the database www.linuxprinting.org some ppd:s seem
> to have a foomatic-rip filter line:
> 
> *cupsFilter:	"application/vnd.cups-pdf 0 foomatic-rip"
> 
> I tried running the foomatic-rip remotely (and testing with the cupsfilter
> command), but it seems to fail asking for a printername, I assume it cannot
> to detect it is working with CUPS.
> 
> sh-3.2$ /usr/sbin/cupsfilter -e -m printer/zzz-aos-sv-305-color1 -p
> /etc/cups/ppd/zzz-aos-sv-305-color1.ppd output.pdf | more
> DEBUG: argv[0]="cupsfilter"
> DEBUG: argv[1]="1"
> DEBUG: argv[2]="lp"
> DEBUG: argv[3]="output.pdf"
> DEBUG: argv[4]="1"
> DEBUG: argv[5]=""
> DEBUG: argv[6]="output.pdf"
> DEBUG: envp[0]="<CFProcessPath>"
> DEBUG: envp[1]="CONTENT_TYPE=application/pdf"
> DEBUG: envp[2]="CUPS_DATADIR=/usr/share/cups"
> DEBUG: envp[3]="CUPS_FONTPATH=/usr/share/cups/fonts"
> DEBUG: envp[4]="CUPS_SERVERBIN=/usr/lib/cups"
> DEBUG: envp[5]="CUPS_SERVERROOT=/etc/cups"
> DEBUG: envp[6]="LANG=en_US.UTF8"
> DEBUG: envp[7]="PATH=/usr/lib/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin"
> DEBUG: envp[8]="PPD=/etc/cups/ppd/zzz-aos-sv-305-color1.ppd"
> DEBUG: envp[9]="RIP_MAX_CACHE=8m"
> DEBUG: envp[10]="USER=lp"
> INFO: Rfoomatic-rip (PID 27733) started.
> INFO: Rfoomatic-rip (PID 27733) exited with no errors.
> No printer definition (option "-P <name>") specified!
> 
> So do you think we could somehow keep running cups 1.4.6 on the server or are
> we forced to upgrade? Is it possible to convert old style pure postscript
> ppd:s to a format suitable for the pdf workflow? Which filters are needed?
> 
> -Johan Bengtsson/Chalmers IT-service
> 
> _______________________________________________
> cups mailing list
> cups at cups.org
> https://www.cups.org/mailman/listinfo/cups




More information about the cups mailing list