Customized settings of cups-pdf are ignored

[quadra]

Binary package hint: cups-pdf

I'd like to customize PDF printing using cups-pdf. However, my modifications in cups-pdf.conf seem to be ignored.
Here is how to reproduce the bug: Edit cups-pdf as below.
Expected result: A test page shoud be printed in grayscale and low resolution.
Actual result: The page prints all right, but the pdf is in color and hi resolution.

cups-pdf.conf is default as installed on Ubuntu 10.04, except for the following:
Modified part of cups-pdf.conf:

    ##############################################
    #
    # PDF Conversion Settings
    #
    ################################################## ###

    ## Some commented-out lines here
    ## The GSCall line is modified and commented out:

    GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dCompressFonts=true -sOutputFile="%s" - dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray -dPDFSETTINGS=/screen -c .setpdfwrite -f %s

===================
Extra info 1:
Also tried to set the GSCall parameter in cups-pdf.conf as follows: GSCall = GhostScript /usr/bin/ps2pdf - no effect

Extra info 2:
I checked debug messages in the /var/log/cups/error_log - there it seems that the custom parameters are not correctly included in the actual GS call. The error log can be found here: http://ubuntuforums.org/showthread.php?t=1512863

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: cups-pdf 2.5.0-12
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Thu Jul 1 20:33:30 2010
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5)
Lpstat:
 device for DESKJET-920C: hp:/usb/DeskJet_920C?serial=HU17P6R2QWBI
 device for Generic-CUPS-PDF-Printer: cups-pdf:/
 device for Lexmark--X1100-Series: usb://Lexmark/X1100%20Series
 device for Virtual_PDF_Printer2: cups-pdf:/
Papersize: A4
PpdFiles:
 DESKJET-920C: HP Deskjet 920c hpijs, 3.9.8
 Generic-CUPS-PDF-Printer: Generic CUPS-PDF Printer
 Lexmark--X1100-Series: Lexmark X73 - CUPS+Gutenprint v5.2.5
 Virtual_PDF_Printer2: Generic CUPS-PDF Printer
ProcEnviron:
 LANGUAGE=en_GB:en
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: cups-pdf

[Till Kamppeter (till-kamppeter)]

The problem is the following:

In Ubuntu we have a PDF-based printing workflow. All jobs arriving at CUPS are turned to PDF by filters which ship with the CUPS package. Then the pdftopdf CUPS filter does page management (N-up, reverse order, selected pages, ...) and then PDF data is passed on to the driver or the backend. As the cups-pdf backend already receives PDF this way it does not call Ghostscript any more but simply passes the incoming PDF through into the output file. Therefore the Ghostscript command line in the configuration file is ignored. If we had cups--pdf not supporting the PDF workflow as before we would get incoming PostScript be turned to PDF, then page management applied, after that the PDF turned to PostScript again for cups-pdf turning it to PDF the second time. Even if all is digital this is not without losses. The quality of the resulting file is much worse, especially in terms of resolution and size, perhaps also in color, than the original file. Having only one conversion from PostScript to PDF gives much better output. Newer applications even output PDF directly and so there is no conversion at all.

[Martin-Éric Racine (q-funk)]

On Thu, Jul 1, 2010 at 10:09 PM, Till Kamppeter wrote:
> In Ubuntu we have a PDF-based printing workflow. All jobs arriving at
> CUPS are turned to PDF by filters which ship with the CUPS package.
> As the cups-pdf backend already receives PDF this way it does
> not call Ghostscript any more but simply passes the incoming PDF through
> into the output file.

It therefore appears that the PDF workflow patch actually cripples
CUPS-PDF rather than enhance it. Given this, I'm beginning to wonder
if it should simply be reverted, because it actually removes
capabilities from CUPS-PDF.

[Till Kamppeter (till-kamppeter)]

Martin-Éric, you do not need to revert to the awkward forth-and-back conversion. The low resolution can also be achieved with the pstopdf filter of CUPS (/usr/lib/cups/filter/pstopdf). One only needs to add a "Resolution" option like this to the PPD file:

*OpenUI *Resolution/Resolution: PickOne
*OrderDependency: 90 AnySetup *Resolution
*DefaultResolution: 600x600dpi
*Resolution 150x150dpi/150 DPI: ""
*Resolution 300x300dpi/300 DPI: ""
*Resolution 600x600dpi/600 DPI: ""
*Resolution 1200x1200dpi/1200 DPI: ""
*CloseUI: *Resolution

Then the user can choose the resolution.

In addition, he can choose all CUPS options already without any changes, like N-up, selected pages, reverse order, ...

[Martin-Éric Racine (q-funk)]

On Fri, Jul 2, 2010 at 3:03 PM, Till Kamppeter wrote:
> Martin-Éric, you do not need to revert to the awkward forth-and-back
> conversion. The low resolution can also be achieved with the pstopdf
> filter of CUPS (/usr/lib/cups/filter/pstopdf). One only needs to add a
> "Resolution" option like this to the PPD file:

Till, the point is that this patch invalidates several fatures that
are expected from CUPS-PDF via Ghostscript options, among other things
the possibility to request greyscale printing.

[Till Kamppeter (till-kamppeter)]

You could also do the following:

As Ghostscript can both read and generate PDF, you could make the use of Ghostscript on PDF code optional using an additional parameter in the config file.

Most users want to have straight use of CUPS' PDF output to get high speed and less risk of quality and file size problems due to converting the file forth and back several times. The leave the config file in the default mode of not using Ghostscript on PDF input.

Some users have special needs and would like to do some changes on the PDF output. They can turn on Ghostscript post-processing on PDF output via the config file to apply arbitrary Ghostscript command lines, even with non-PDF output.

[Fabián Rodríguez (magicfab)]

Till, thank you for your comments. This originated from a customer (the original reporter). I have reproduced this locally so I confirmed it.

My workaround was to use ps2pdf directly, which works as expected, although is not ideal but we support. I still wanted to open a bug as the original reason the configuration file was modified at all was the lack of UI to choose the options in the first place.

This remains about the config file options being ignored. Would it be useful to open a separate bug about the missing UI elements ? If I understand #4 correctly, such modifications to the PSD file would bring UI elements to chose parameters for cups-pdf to use ?

[Till Kamppeter (till-kamppeter)]

Yes, a second bug for adding UI elements to control the process of PDF generation would make sense, but note that it is more a feature request than a bug report.

Yes, each "*OpenUI...*CloseUI" section in the PPD file is one printer option in the printing dialog.

[Martin-Éric Racine (q-funk)]

Please note that CUPS-PDF is just a CUPS back-end meant to be treated as just any printer with a fixed set of features. Adding any sort of UI to what is essentially a printer driver, rather than a PDF export tool, would not be an easy task.

As for the process of PDF generation in general, please note that the generic GTK2 print dialog already supports configuring a number of print options for its own Save to PDF feature. The same functionalities are also offered by QT for KDE apps. These two toolkit-specific features are the preferred methods for generating PDF documents from an Ubuntu desktop. Meanwhile, CUPS-PDf is instead designed for massively replacing printouts with PDF documents in a corporate setting.

[quadra (info06)]

Many thanks to all the experts for the highly interesting discussion.
From the user perspective, I would suggest to take the importance of feature-rich PDF generation seriously. Not just corporations, also more and more individuals switch to paperless environments. They need seamless but also feature-rich PDF support, beyond just setting some global image resolution. E.g. different resolution for color/grayscale/black&white images, thresholds for downsampling, options for converting to monochrome or reducing color palette, jpg compression strength, font embedding, PDF/A, page rotation, merging of documents, bookmark auto-generation. Will application-specific PDF export features replace a hi-quality, generic PDF printer? I doubt. So indeed it's probably a feature request, be it for ubuntu native printing or for cups-pdf in ubuntu. For the average user these options should be available in an ui (I tried to understand the ghostscript manpages and also looked into ppd files, /user/lib/cups/pstopdf etc but it's just too hard). But at least Ubuntu shouldn't "invalidate" cups-pdf!
Thank you!

[Martin-Éric Racine (q-funk)]

Thank you for taking the time to report this bug. Could you please test this against the current version of "cups-pdf" found in my Personal Package Archive (PPA) at https://launchpad.net/~q-funk/+archive/ppa and confirm whether the issue still applies?

[quadra (info06)]

Thank you so much, your fixed version works!
I can now configure CUPS-PDF with specific settings using the GSCall line in /etc/cups/cups-pdf.conf.
(Status -> fix committed?)

[Martin-Éric Racine (q-funk)]

Fixed released as of 2.5.1-1 in Natty.

[Brock Sides (philarete)]

Tried your 2.5.1-1 Meerkat package, hoping to get ability to use modified GSCall line in /etc/cups/cups-pdf.conf. However, this package only yields empty pdfs with no content, no matter what I try to print.

[Martin-Éric Racine (q-funk)]

Brock, thank you for reporitng this. It is, however, an entirely different issue, which is already adressed in another bug.

[Brock Sides (philarete)]

Bug 487629?

https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/487629

[Brock Sides (philarete)]

Deleting and re-adding the PDF printer after installing your cups-pdf package fixed the problem.

[Martin-Éric Racine (q-funk)]

Brock, that sounds like a really odd way to fix it. Do you notice any difference between the PDF printer created automatically by the package at installation time and the one that you maanually created?

[Brock Sides (philarete)]

I think the one I deleted (which was printing blank PDFs) was the one created by the stock cups-pdf package, which didn't get deleted when I purged the package.

[Brock Sides (philarete)]

I can confirm that this problem occurs when your cups-pdf package is installed without removing the printer "PDF" created by the stock package. Also, it seems that "apt-get purge" on the stock cups-pdf package sometimes removes the printer "PDF", and sometimes does not.

[Martin-Éric Racine (q-funk)]

Can you notice anything different in the CUPS settings for those two printers? Is the one that you created manually perhaps sing a different PPD? I'm just trying to figure out why the one created at install time wouldn't work and the one created manually does.

[Brock Sides (philarete)]

Looking at /etc/cups/printers.conf, the only obvious difference between the print PDF created by the stock maverick cups-pdf-2.5.0 package, which prints blank pages after upgrading to your cups-pdf-2.5.1 package, and one created manually after the upgrade, are the Filter lines.

In the original one created by cups-pdf-2.5.0:

Filter application/vnd.cups-raw 0 -
Filter application/vnd.cups-pdf 0 -
Filter application/vnd.cups-postscript 100 -
Filter application/vnd.cups-command 0 commandtops

The one manually created after upgrading to cups-pdf-2.5.1:

Filter application/vnd.cups-raw 0 -
Filter application/vnd.cups-command 0 commandtops
Filter application/vnd.cups-postscript 0 -

The "application/vnd.cups-pdf" line is not present when the printer is created manually after the upgrade.

The PPD file is also different. The original:

root@sides-laptop:cups# ls -l ppd
total 612
-rw-r--r-- 1 root root 21061 2011-04-21 09:07 PDF.ppd

The newly created one:

root@sides-laptop:cups# ls -l ppd
total 612
-rw-r--r-- 1 root root 20956 2011-04-21 09:14 PDF.ppd

I'm also seeing very inconsistent behavior with regard to removing the PDF printer when the cups-pdf packages (both the stock one and your 2.5.1 package) are purged. Sometimes the PDF printer is removed, sometimes it isn't.

[Martin-Éric Racine (q-funk)]

Brock, thanks for these additional precisions. What I'm especially interested in are the differences between the automatically added printer and the manually added one, in both cases using 2.5.1-2 packages.

[Brock Sides (philarete)]

Having trouble determining that. It seems that if the PDF printer is deleted using "lpadmin -x", installation of cups-pdf (both 2.5.0-16 and 2.5.1-2) doesn't automatically create the PDF printer, and you have to create it manually.

Anyway, as far as I can tell the issue arises only when the PDF printer created under 2.5.0-16 is not deleted before the upgrade to 2.5.1-2. The problem doesn't arise if 2.5.1-2 creates the PDF printer automatically, or if the PDF printer is created manually after the installation of 2.5.1-2.

[Martin-Éric Racine (q-funk)]

Debian bug 617468 seems to be about the same blank page issue. I'll report on Brock's findings there and see what happens.