Concepts printing

Jump to: navigation, search
Documentation> Concepts
Basis - Package management - Multimedia - Interface - Directory structure - Networking - Printing - Security - Hardware


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.

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" (i.e. printer-model-specific data) that the particular printer accepts.

In general "driver" means device-model-specific software and data.

Further information:

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.

On http://www.linuxfoundation.org/collaborate/workgroups/openprinting there was the following: 

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.

Further information:

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. CUPS is now developed at OpenPrinting https://openprinting.github.io/cups/

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").

Further information:

Printer drivers: Make the printer print

In general "driver" means device-model-specific software and data.

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.

Some standard printer driver and PPD files packages:

  • gutenprint: the Gutenprint driver and its matching PPDs
  • 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.

Further information:

User expectations

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’ http://mmiworks.net/ partner company
relevantive http://relevantive.de/ 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, cups-filters, Ghostscript, and printer driver projects).

See also

Retrieved from "https://en.opensuse.org/index.php?title=Concepts_printing&oldid=183171"