This way cups-pdf as provided by upstream disqualifies itself for being part of Debian and Ubuntu distributions. Practically all applications send their print jobs in PDF format and CUPS in Debian and Ubuntu is configured to respect this by maintaining the data stream format in PDF until sending the job to the renderer/driver, so a tool like cups-pdf should work well with PDF input
Most users simply want a tool which drops the job as PDF file in their home directory. This is nicely fulfilled by my patch which was applied to cups-pdf earlier. The job principally stayed the original PDF output of the application (speed reliability) and only got modified by the pdftopdf filter of CUPS in the case of the user using CUPS' page management options (N-up, reverse order, selected pages, ...). Some users want to have the possibility of applying additional manipulation to their print-to-PDF jobs via the settings in the /etc/cups/cups-pdf.conf config file. What can be done there (except file name, user, and security settings which are independent of the use of Ghostscript) is merely editing the Ghostscript command line which was intended to turn PostScript into PDF and the PDF level to convert to this PDF level. So what is mostly needed of the original cups-pdf is the mechanism to save print jobs as PDF files in a given subdirectory the user's home directory, assign the desired permissions and the desired file name scheme. In most cases the user wants to have the PDF coming out quickly and not being blown up by unneeded conversions. As the data already comes in PDF, this PDF should be dropped in the user's directory if the user did not express special desires via the /etc/cups/cups-pdf.conf file. So default should be a pass-through of incoming PDF. A conversion with Ghostscript should be only done either if the input is PostScript (usually does not happen in Debian or Ubuntu) or if the user explicitly desires a conversion by giving a Ghostscript command line or a PDF level in /etc/cups/cups-pdf.conf, and as Ghostscript also understands PDF, PDF input should never be converted to PostScript only for feeding it into Ghostscript. Ghostscript simply re-renders incoming PDF to the desired alternative PDF format (other level, quality, ...). So I suggest the following changes on cups-pdf (being our fork if upstream does not accept them): - The PPD file makes the tool accepting both PostScript and PDF, PDF with a lower cost factor, to assure a PDF printing workflow on systems with the pdftopdf filter installed (Debian, Ubuntu): *cupsFilter: "application/vnd.cups-postscript 100 -" *cupsFilter: "application/vnd.cups-pdf 0 -" - The backend only calls Ghostscript if at least one of these three conditions is fulfilled: 1. The input data is PostScript 2. The user specifies a custom Ghostscript command line via "GSCall" in /etc/cups/cups-pdf.conf 3. The user specifies a custom PDF level via "PDFVer" in /etc/cups/cups-pdf.conf Otherwise Ghostscript is not called and incoming PDF is simply saved in the user's directory. Default is "GSCall" and "PDFVer" not being set so that PDF gets simply saved. This allows quick, reliable, and resource-saving PDF printing and perfect integration in the new standard but does not take away configurability. Martin-Eric, WDYT about that? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/820820 Title: cups-pdf should not convert PDF print jobs to PS then to PDF To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/820820/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
