- 1 Common printing data formats
- 2 PPD files: Printer-specific options
- 3 CUPS: The server between user and printer
- 4 Printer drivers: Make the printer print
- 5 User expectations
- 6 See also
Common printing data formats
PostScript: The traditional printing data format
Linux uses a common data format for printing: The PostScript format. This means that application programs usually produce PostScript output when printing.
Some printers accept PostScript natively, i.e. PostScript printers can print application's printing output directly. Other printers need Ghostscript plus a printer driver which convert PostScript into the "language" that the particular printer accepts.
- Linux printing details: http://www.linuxfoundation.org/collaborate/workgroups/openprinting
- PostScript and wikipedia:PostScript
- Ghostscript and wikipedia:Ghostscript
PDF: The recent printing data format
There is a general move away from PostScript to PDF as the standard print job format. This change is advocated by the OpenPrinting workgroup of the Linux Foundation and the CUPS author.
See http://www.linuxfoundation.org/collaborate/workgroups/openprinting which reads:
PDF is the standard print job format from CUPS 1.6.x on
All important desktop applications (GTK/GNOME, Qt/KDE, LibreOffice/OpenOffice.org, Firefox, Thunderbird, ...) send print jobs in PDF and not in PostScript any more by default. In addition, a complete CUPS filter chain to process print jobs in PDF is available and used.
CUPS author Mike Sweet/Apple have decided to not include the Linux-specific CUPS filters in the upstream CUPS source any more and we have agreed to maintain them at OpenPrinting. Here we have done some clean-up and have discontinued the filters for the PostScript-centric workflow in favor of the PDF workflow, meaning that the upstream standard for CUPS under Linux (using CUPS plus our cups-filters package) is the PDF-based job processing, letting every non-PDF input be converted to PDF first, page management options being applied by a pdftopdf filter and Ghostscript being called with PDF as input.
Only exception is if the input data is PostScript and the printer is a PostScript printer or the printer driver requires PostScript as input. The [sic] we do not turn PostScript into PDF and back into PostScript but pass the PostScript through the pstops filter as before.
Having this workflow we ask all driver developers kindly to not create any PPDs/drivers for non-Postscript printers which require exclusively PostScript. PPD files should at least accept PDF or CUPS Raster now. See also our driver design/packaging page http://www.linuxfoundation.org/collaborate/workgroups/openprinting/writingandpackagingprinterdrivers
More info on our page about the PDF printing workflow http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdf_as_standard_print_job_format and on the cups-filters page https://www.linuxfoundation.org/collaborate/workgroups/openprinting/cups-filters.
PostScript versus PDF as standard print job format
In contrast to PostScript the PDF format is a de facto standard that is commonly used for worldwide document interchange which makes the PDF format most suitable to be also used as standard print job format regardless that in particular related to printing the PDF format has drawbacks compared to PostScript.
With PDF as the standard print job format traditional PostScript printers can no longer print application's printing output directly so that a conversion step in the printing workflow is required that converts PDF into PostScript (usually via Ghostscript). But there are also PostScript+PDF printers that can print both PostScript and PDF directly.
For PostScript there are three versions (called "levels"): Level 1, level 2, level 3 where each is a superset of the former (see https://en.wikipedia.org/wiki/PostScript). Additionally there is the DSC specification (see http://en.wikipedia.org/wiki/Document_Structuring_Conventions).
There is no such thing as THE PDF format.
For PDF there are various versions and many different subsets where each subset again can have various different versions (e.g. PDF/A-1 PDF/A-2 PDF/A-3, PDF/X-1, PDF/X-1a, PDF/X-3, PDF/X-4, PDF/X-4p, PDF/X-5, PDF/X-5g, PDF/X-5pg, PDF/X-5n, PDF/VT-1, PDF/VT-2, ... and so on ad nauseam) see http://en.wikipedia.org/wiki/Portable_Document_Format and follow the links therein.
PDF is only partially an open standard. There are still some technologies that could be used in PDF files, that are defined only by Adobe and remain proprietary (see http://en.wikipedia.org/wiki/Portable_Document_Format).
Accordingly free software applications and tools that support PDF in general cannot support all the possible features that are supported by original Adobe programs (cf. Adobe Reader). Adobe is inventing more and more new features that take time to go into the open standards and then additional time until they get supported by free software applications and tools.
When printing "just PDF" it is basically more or less luck what that results as printout because it depends on how much built-in "intelligence" the programs have (usually Ghostscript) that convert the "just PDF" data into printer specific data.
For example transparency is by design problematic, see http://en.wikipedia.org/wiki/Portable_Document_Format#Transparency and http://en.wikipedia.org/wiki/Transparency_%28graphic%29#Transparency_in_PDF
In contrast to "just PDF" which has zillions of fancy features (also think about various kind of interactive elements and so on) PDF/A-1 is a subset of the whole PDF specification that is intentionally meant to have only a minimal feature set to work stable over the time.
But contradictorily even PDF/A gets enhanced and enhanced with new features over the time, see http://en.wikipedia.org/wiki/PDF/A
This means when one wants to ensure that the printout looks as intended, one should let the application produce PDF/A-1.
Unfortunately most applications do not support any PDF/A. Usually applications only support "just PDF".
Alternatively there is also PDF/X in various flavours (PDF/X-1a,... PDF/X-4, PDF/X-4p, PDF/X-5pg,...), see http://en.wikipedia.org/wiki/PDF/X
PPD files: Printer-specific options
PostScript Printer Description (PPD) files list printer-specific values and options and the possible choices for each option like:
- Page size: A4, Letter, Legal
- Paper input slot: Default, Envelope, ManualFeed
- Printing resolution: 300x300dpi, 600x600dpi
Application programs use PPD files to show the printer-specific options in their printing dialogs and to get printer-specific values that are of interest when applications produce PostScript or PDF output for printing like:
- Monochrome or color printer
- Printable area values for each page size
Printer setup tools (e.g. the YaST Printer module) use the following values from PPD files to list printer models:
- Printer manufacturer
- Model name
For PostScript printers the manufacturers provide a PPD file for each particular printer model.
For other printers (i.e. non-PostScript printers) the printer driver software package usually contains PPD files for the printer models which are supported by the particular printer driver. For non-PostScript printers, the PPD file contains the information which printer driver program must be used and the printer-specific options that are available for the particular driver.
- SDB:CUPS in a Nutshell: PPD Files
CUPS: The server between user and printer
The Common Unix Printing System (CUPS) is the base printing system developed by Apple Inc. for Mac OS X and other UNIX-like operating systems, in particular Linux.
A printer device is not used directly by user application programs but via a print queue.
When various application programs submit print jobs simultaneously, these jobs are put in a queue and sent one after the other to the printer device. Even when a single user with one application program submits a single print job, the print queue holds the job so that the application program can continue and the user does not need to wait until the printer device had finished to actually print it.
CUPS is the software which must run on a computer so that application programs can send their printing output to CUPS which queues the print jobs and processes them one by one.
For each print queue there is a PPD file which CUPS provides to application programs so that the printer-specific options are available in the printing dialogs.
In particular for non-PostScript printers CUPS runs the printer driver and sends its result to the printer device. To do this, CUPS must know which printer driver belongs to the printer device and how the printer device is connected to the computer so that CUPS can send printing data to the printer device.
Therefore "set up a printer" means to "set up a print queue" and tell CUPS for the particular queue:
- How the printer device is connected to the computer
- Which printer driver belongs to the printer device (via the PPD file)
Strictly speaking from the computer's internal point of view it usually doesn't know about the actual printer devices but only about print queues. What CUPS and application programs call "printers" are usually not the actual printer devices but only their associated print queues. This sketchy usage of the word "printer" for the computer's internal representation can lead to confusion when it is not clear for the user what it actually means when CUPS or application programs show that everything is o.k. with the "printer". Usually this means that the state of the print queue is o.k. (e.g. "ready") but the state of actual printer device could be different at the same time (e.g. "out of paper").
Printer drivers: Make the printer print
The printer driver produces the final printer-specific data which actually lets the printer print.
Each driver accepts only certain printing data formats and produces data compatible with only certain printer models. If a wrong driver is used, wrong data is sent to the printer which produces bad looking printout, chaotic printout, or no printout at all.
Even if a printer is listed as "supported", there could be minor differences between an application's PostScript printing output and the actual printout on the paper when the driver is not specifically optimized for the particular printer model (see SDB:Purchasing a Printer and Compatibility).
PostScript printers do not need a printer driver because they do not need driver software which converts PostScript into another "language" that the printer actually "understands". For example such a printer language is PCL (Printer Command Language developed by Hewlett-Packard).
PostScript printers need only a PPD file which matches the particular model to make the printer-specific options available to application programs.
Other printers (i.e. non-PostScript printers) need printer driver software plus a PPD file which matches the particular driver.
Usually there is neither such a thing as "the one and only driver" nor is there such a thing as "the best driver" for a particular printer model. The better the printer hardware is, the more different drivers are available, where each driver is best only for a particular use case.
For example a PostScript+PCL color laser printer could be operated as
- PostScript printer using a PostScript PPD
- color PCL printer using a PPD for a color PCL driver
- monochrome PCL printer using a PPD for a monochrome PCL driver
Printing via a PCL driver is usually faster but with less quality than printing in PostScript mode and using a monochrome PCL driver is probably the best way to enforce fast monochrome-only printing.
More information regarding PostScript+PCL printers:
openSUSE printer driver software packages
See the "Driver" section in YaST Printer how to install printer driver software packages with the YaST printer setup module.
Up to openSUSE 11.3 the cups-drivers package was a huge all-in-one package which contained several actually independent printer drivers and several sets of PPD files.
Since openSUSE 11.4 the following printer driver and PPD files packages are split from the cups-drivers package and the cups-drivers package itself is dropped:
- gutenprint: the Gutenprint driver and its matching PPDs
- splix: the SpliX driver and its matching PPDs
- m2300w: the m2300w driver and its matching PPDs (unmaintained => dropped since openSUSE 13.2)
- OpenPrintingPPDs-ghostscript: PPDs for Ghostscript built-in drivers
- OpenPrintingPPDs-hpijs: PPDs for the HPIJS driver for non-HP printers
- OpenPrintingPPDs-postscript: PPDs for PostScript printers
Additionally there is HP's Linux Imaging and Printing (HPLIP) driver solution for HP printers and scanners in HP all-in-one devices. It includes the Ghostscript printer driver HPIJS with matching PPDs and the native CUPS printer driver HPCUPS with matching PPDs plus the SANE scanner driver hpaio. openSUSE provides HPLIP in the packages hplip and hplip-hpijs and since openSUSE 12.1 additionally in the package hplip-sane, see SDB:How to set-up a HP printer.
Furthermore since openSUSE 12.1 there is the Epson Inkjet Printer Driver (ESC/P-R) for Linux. openSUSE provides it in the package epson-inkjet-printer-escpr.
Finally more PPD files from printer manufacturers for PostScript printers are provided in the package manufacturer-PPDs.
Regarding "Version upgrades for printer driver packages" see SDB:Installing a Printer.
- SDB:CUPS in a Nutshell: The Filter (includes the Driver)
- OpenPrinting.org Driver List: http://www.openprinting.org/drivers
- Gutenprint driver: http://gutenprint.sourceforge.net/
- HPLIP home page: http://hplipopensource.com/
Linux standard printer driver development
The LSB (Linux Standard Base) DDK (Driver development kit) can be used to provide distribution-independent printer driver packages for Linux.
Printer manufacturers and printer driver developers can package their printer driver software and make it available as distribution-independent software package.
This way users can install those drivers if their distribution does not or cannot ship them or ships it only in an outdated version.
Printing should work without attracting attention.
End user expectations
The usability experts Peter Sikking and Jan Mühlig did some research with real average users. Peter Sikking wrote at http://www.mmiworks.net/eng/publications/labels/openPrinting.html
1st rule of printing: printing does not exist
m+mi works’ partner company, relevantive, performed user research at the beginning of this project. It showed that for users there is no worthwhile, productive activity between the moment they want to see something printed and the moment it comes out of the printer.
I was curious to find out what users expectations are apart from get it on paper when they print. So Jan did some user testing.
And guess what: there is no such thing as printing.
It does not exist as a task, as a meaningful activity. One moment you decide to see it on paper, the next it rolls out of the printer.
This means that end users are usually neither interested in sophisticated printing features nor in famous innovations at the expense of incompatible changes. What end users want is that printing works without attracting attention.
System admin expectations
What experienced system admins want is that printing works as designed and documented by the matching upstream projects without the need for special attention.
This means printing should work without unexpected behaviour in particular without special openSUSE specific stuff and without behavioural changes all of a sudden.
Therefore regarding "Printing" openSUSE is in full compliance with the various upstream projects (mainly CUPS, Ghostscript, and printer driver projects).
- Portal:Printing for an overview