SDB:Printing to PDF
Security warning!
Do this only if you know about the consequences, in particular when running a multi-user system. This may cause a denial of service (spool directory fills up so that the harddisk may run full), no privacy of data (anyone may read the PDFs), or specially crafted printjobs might be able to cause security issues.This article is for CUPS up to version 2.x under Linux with the traditional filtering system and backends there.
The nowadays driverless printing workflow is rather different.
Printing to PDF from Desktops
Depending on which desktop system (in particular Gnome versus KDE) is installed and depending on which version of the desktop system is used and depending on which additional packages are installed, the desktop system may already provide a Print to PDF or Save as PDF functionality (see below) out-of-the-box so that there is no need for CUPS-PDF.
Download and install the cups-pdf package
Go to the software search page, and search for the cups-pdf package for your version of openSUSE.
Preferably use the package from the "Printing" repository.
Read the "Printing" project description at https://build.opensuse.org/project/show?project=Printing
To download RPM packages manually from the "Printing" repository use http://download.opensuse.org/repositories/Printing/ and go to the matching sub-directory for your particular system and architecture (in particular 32-bit i586 versus 64-bit x86_64).
If you install software from whatever arbitrary repository, make sure you really know what you do. Is it really the exact software which you expect? Does it really match your currently running system?
Set up a print queue for cups-pdf
A print queue must be set up so that user application programs can print, see Concepts printing. In this case a special print queue is set up which does not print to a real printer device but stores the printout as PDF file.
Any printer setup tool which works in compliance with CUPS can be used.
- Instead of a real printer device "Virtual PDF Printer (CUPS-PDF)" must be selected which uses the CUPS device URI "cups-pdf:/".
- The matching printer driver is "Generic CUPS-PDF Printer" (under the manufacturer "Generic") which uses the PPD file "/usr/share/cups/model/CUPS-PDF.ppd".
As user root via lpadmin command it could be done as follows (see "How to set up a print queue in full compliance with CUPS" at SDB:CUPS in a Nutshell):
lpadmin -h localhost -p cups-pdf -v cups-pdf:/ -P /usr/share/cups/model/CUPS-PDF.ppd -E
Alternatively when you use for example the CUPS web frontend to set up the print queue, the procedure is like (depending on the CUPS version it could be different):
- Open the CUPS web frontend http://localhost:631 using a web browser like Firefox.
- Use the "root" username and password (or any username with CUPS admin rights) when prompted for authentication.
- Select the Administration tab and click "Find New Printers".
- You should see Virtual PDF Printer (CUPS-PDF), click "Add This Printer" and then "Continue".
- In the next screen "MAKE/MANUFACTURER FOR CUPS-PDF", select Generic and click "Continue". Then select Generic CUPS-PDF Printer and click "Add Printer".
- Optionally change the default page size to match the locality (i.e. A4 versus US Letter) under the PDF:General, Page Size setting.
Adjust permissions for cups-pdf
cups-pdf provides the CUPS backend /usr/lib/cups/backend/cups-pdf which needs root privileges to set the file ownerships for the PDFs to the user who submitted the print job. You may have a look at "What is a CUPS backend and how does it work" in SDB:CUPS in a Nutshell.
By default the permissions for cups-pdf should be correct.
In exceptional cases you may have to run the following command as root so that /usr/lib/cups/backend/cups-pdf is run as "root"
chmod u=rwx,go= /usr/lib/cups/backend/cups-pdf
because since CUPS 1.2 backends without world execute permissions are run as the root user, see "man backend".
For CUPS 1.1 you may have to use something like
chmod u=rwxs,go= /usr/lib/cups/backend/cups-pdf
or even (when a CUPS 1.1 cupsd runs as user "lp")
chown root:lp /usr/lib/cups/backend/cups-pdf chmod u=rwxs,g=x,o= /usr/lib/cups/backend/cups-pdf
so that the CUPS backend is run as setuid root program.
Configuration options for cups-pdf
The configuration options are stored and described in the /etc/cups/cups-pdf.conf file. For some hints and notes see also /usr/share/doc/packages/cups-pdf/README.
PDF output location
The default location for the PDF files is
/var/spool/cups-pdf/yourusername/
To change this, edit the /etc/cups/cups-pdf.conf file. For example to store the PDF files in the "Desktop" directory in each user's home directory you may set:
Out ${HOME}/Desktop
In this case have in mind that the printing system cannot store files at arbitrary places, see "Background Information regarding Print as PDF versus Save as PDF" below.
External links
Background Information regarding Print as PDF versus Save as PDF
User applications (including user print dialog programs) run on the user's local machine as a user's process under the user's ID (i.e. they run in the user's personal environment). Therefore user applications can store files (e.g. PDFs) in the user's home directory (or wherever the user has specified in the application).
On the other hand the processes of the printing system do not run under the user's ID and in case of printing in the network they even run on an arbitrary different machine in the network.
Therefore the printing system cannot store files in whatever place which was specified by a user who has submitted a print job.
On a single-user stand-alone system it works to print to a "PDF printer" which stores a PDF at a predefined file location but this can cause issues in a multi-tasking multi-user networked system.
Some applications provide a "print to (PostScript/PDF) file" functionality. This is done by the user application itself. No printing system is involved when the user application does not send its printing output to a print queue but instead stores it into whatever file the user likes.
The wording "print to file" is misleading because what actually happens is "save as (PostScript/PDF) file".
Probably the reason for the confusion with the wording is that the "save as PS/PDF" functionality is often not found in the "File" menue. Instead in the "Print" menue a "print to file" option can be found and fortunately this results a PostScript or PDF file so that for the user it looks as if printing is done when he likes to do "save as PS/PDF file".
Strictly speaking "save as PS/PDF" and "print to file" are not the same regarding the result. Only "save as PS" guarantees that the result is a PostScript file and "save as PDF" guarantees that the result is a PDF file.
In contrast "print to file" can result whatever arbitrary printer-specific (binary) data which the application produces to be sent as print job.
Only by luck (more precisely because PostScript or PDF is the usual data format when Unix/Linux applications produce data for print jobs, see Concepts printing) it happens that "print to file" can be misused when there is no "save as PS/PDF" functionality in the application.
There is no guarantee that such a PostScript or PDF file could be printed later on any printer because it could be printer-specific PostScript or printer-specific PDF. For example OpenOffice is known to produce printer-specific PostScript so that such a PostScript file may only print on the printer for which OpenOffice has made it.
When there is no "save as PS/PDF" functionality in the application a possible workaround on a stand-alone system is to set up a "PDF printer" which stores a PDF at a predefined file location to get hopefully a printer-independent PDF file.
The real solution is to have a properly implemented "save as PDF file" functionality in the application which really results a printer-independent PDF file.
A printer-independent PDF file should be PDF/A - preferably PDF/A-1 - or PDF/X (see "PostScript versus PDF as standard print job format" at Concepts printing).