In this OpenPrinting forum:General Discussion. This is the successor of the same named forum previously hosted atopenprinting.org.

PostScript is a programming language which specializes in placing text and images on paper. It is the most accurate method for laying out text, images and graphics on a page.

Yes. Traditionally, PostScript is created by most applications by default whenever they are asked to print.

Not directly. Windows internally uses a different format for page descriptions of printable documents. To print to PostScript printers, Windows uses a special program to convert documents: it is called a “PostScript printer driver”.

Yes. Apple operating systems use PostScript for printing. Apple even experimented with “Display PostScript” on the Macintosh in 1984 in order to draw the user interface elements on screen.

The PostScript language is described in an open specification created by Adobe Inc.; it is well defined and free to use by anyone who so desires. Printers that do not understand (standard) PostScript tend to speak one of many different “languages”, most of them proprietary and not openly documented at all.

PostScript is a fullblown programming language. That allows a lot of flexibility. Features can be implemented to do just about anything before sending the job off to the actual printing device. These include: changing fonts, printing 2,4,8, or 16 pages per sheet; “inverting” the colors; clipping, scaling, warping, rotating pages; landscaping/portrait printing; and much more.

PostScript printers are more expensive than standard consumer printers. Most consumer printers currently do not support PostScript, and very likely never will.

A PostScript printer can read and understand valid PostScript code sent to it. By “interpreting” this code, it translates the data into raster images that are put on sheets of paper. PostScript printers ship with builtin PostScript “interpreters” (a.k.a. “Raster Image Processors”).

No. However, PostScript in principle is easily converted to whichever printjob format you printer consumes. A “printer driver” is doing this conversion. (In the Unix and the GNU/Linux world we usually call this conversion “filtering”, and the program doing so, a “filter”.)

The most famous such program is called “Ghostscript”. Ghostscript is unique in that it embeds in itself many different filters (or printer drivers) at once, and can convert PS to many different device specific formats. Hence, Ghostscript can drive many non-PostScript devices, even if most applications only know to produce PostScript for print files.

By using an “external” PostScript interpreter, implemented in software, hosted on your workstation or on a print server. This interpreter can automatically run specific filters/drivers as needed. CUPS comes with a builtin PostScript interpreter based on Ghostscript.

Yes and No.

“No”, not for basic printing. PostScript printers should be able to print PostScript files directly, without any extra filter or driver. (Caveat: older “Level 1” devices may not print “Level 3” PostScript files.)

“Yes”, if you want to use advanced print job control (printing on both sides of a sheet; punching the output; make the printer do inline stapling to create a pamphlet job; use a differently colored paper or a letterhead sheet for the first page;…), a “PostScript-to-PostScript” filter needs to add specific job control snippets (PostScript or PJL code) inside the print file, before it goes to the printer.

Yes, always.

There are various driver families available on GNU/Linux. They all offer drivers to convert PostScript to whatever various printers need.

• CUPS builtin drivers (not yet mentioned, developed by //Easy Software Products//), available under a Free Software license.
• Ghostscript (mentioned above, developed by //artofcode LLC//), available under a Free Software license.
• HPIJS/HP Inkjet (not yet mentioned, developed by //HP//), available under a Free Software license.
• Gutenprint (not yet mentioned, evolved from Gimp-Print, developed by a small community of people with sophisticated color printing needs), available under a Free Software license.

If you did not explicitly seek out PostScript printing as a feature, it is likely you don't have it. (If in doubt, send a small PostScript testfile {such as <i>/usr/share/cups/data/testprint.ps} to the printer: if it doesn't print at all, or if it prints only some pages of ASCII characters, it is not one.)

Here is a list of models by manufacturer:printer list on openprinting.org (or, if you need the exact URL on your printout of this page:http://www.openprinting.org/printer_list.cgi). Each model entry on this list also names the driver(s) recommended or useful for that device.

PPD is short for PostScript Printer Description. A PPD is just a text file which exactly describes (in a well-defined format) all supported features of a printer and contains the exact code that needs to be injected into the printjobs to invoke each desired feature.

Print software programs can read PPDs, and know how to display the supported features in the printer driver's user interface shown on screen. If the user makes specific choices (like duplex, stapling), the program will know what specific code to inject into the printjob and how to work with the print device. (Note: As an example, the exact code to print a job as “duplex” {i.e. both sides of a sheet} may be different from one model to the next.)

A PPD describes all capabilities of a PostScript printer. This includes available fonts (built into the printer), duplexing capabilities, media sizes handled, non-printable margins for each media size, available resolutions, installed and so on.

Usually yes. Two points to take care off:

• Using one that is labelled “for Apple operating systems” may not work on GNU/Linux!
• Many vendors still do not label their PPDs for Linux suitability; however those suitable for “MS Windows NT” usually work just fine for us (GNU/Linux with CUPS).

PPD files are available from many places:

• openprinting.org
• Manufacturer websites
• Driver disks

Most current Linux distributions ship a big selection of PPDs already on their installation media too.

The PPD should be made for your printer model, or for one similar to yours.

Yes. Since CUPS acts as a PostScript interpreter for all supported non-PostScript models, it is natural to use PPDs (and their well-defined file format) to control all aspects of a printing device. CUPS extended the original PPD specification created by Adobe in that it adds information about which specific filter to use for the target device that converts PostScript to printer-specific raster, or otherwise, data. (The filter information is contained in the PPD in a way that does not disturb other PPD consuming programs.)

In principle, yes. But if you are not a PPD expert, we do not advice you to do so. Programs are very sensitive to the structure and exact syntax of the PPD file; making manual changes can cause reading the file to fail.

If you want to edit it anyway (quite a few people have done so successfully), make a backup first. Know where to look for the PPD file format specification.

Ghostscript is a software that interprets the PostScript (instruction) files. Ghostscript is able to translate these instructions (which mostly describe how the visual appearance of pages should show images, text and graphics) into other “printer languages”.

Ghostscript converts PostScript files into raster “pictures” or commands that your non-PostScript printer can understand. The PostScript language is described in an open specification created by Adobe Inc.; it is well defined and free to use by anyone who desires. Printers that do not understand (standard) PostScript tend to speak many different “languages”, many of them proprietary, and not openly documented at all.

Many. Virtually each one of the major vendors has developed his own printing language. Some manufacturers support not only their own language, but also that of one or more of the competitors.

For a nearly exhaustive list, look at the website of //Undocumented Printing//. The most commonly known ones are:

• AFPDS (IBM)
• PCL (HP)
• HP/GL (HP)
• ESC/P (Epson)
• RPCS (Ricoh)

If you want to understand every aspect of printing and print file conversions, yes. In practice, however, most current Linux distributions nowadays do a good job to support printing for many different models, and automatically configure the printing software with little user input.

Many people never need to know more than the name of their printer to setup their printing during install time.

However, there are still more than enough cases where this process does not work as desired (especially with printing hardware that is not supported for Linux by their vendors). We are working hard to make improve that user experience even more.

Sending print files directly to the printer, without buffering or filtering.  The printer stores the information in its own memory while printing out the file.

Most printers usually can take and process only one print job at a time. In multi-user environments with shared printers, allowing every user to access each printer directly very frequently leads to “clashes” (the same is true even for a single user printing multiple jobs in short intervals).

In the best case, users have to wait for a previous job to be completed by the printer. Until this is done, his current “directly printing” job is waiting and blocking his other intended actions even to the point of freezing his current user interface.

Spooling is said to mean “Simultaneous Peripheral Operation On Line”, and is simply a way to create a queue of tasks for a device, such as a printer. Spooling lets all users and applications hand-off print jobs very quickly to a special program (or the operating system) designated to handle this function. This program first buffers (or caches) the jobfile (usually on a special directory on the harddisk) and then handles all communication with the printer. It waits patiently for the printer to finish with any existing task, while it “queues up” the jobs in the order received, until the printer is free again and able to accept the next job.  After handing a printjob off to the “spooler” program, the user's interface is immediately ready for the user's next task, thereby keeping him or her from further waiting.  Spooling tasks can be a big benefit to personal productivity.

A few years ago it was different….., but nowadays most GNU/Linux distributions have been standardizing on the//Common Unix Printing System// (CUPS) which comes with a builtin spooler. However, should you want to use a different spooling software, openprinting.org (luckily) has documented the most important ones.

No. Not unless your job is to troubleshoot a printing problem.

Generally, the spooler uses various helper programs to accomplish his jobs (filters, backends). The sequence is this:

1. Your program passes a print job (in most cases a PostScript file) to the spooler (in most cases to CUPS) once you have selected the printer (in case you have a choice of several).
2. The spooler determines if the job needs any filtering. If so, it runs the filters on the job as required. (If the file was not PostScript, the first filter invoked may be one that converts the input into PostScript in the first place.)
3. Finally, the spooler contacts the print device and sends the file off (either PostScript “as-is”, or PostScript stuffed with specific job control codes according to your preverences, or even converted to a different-from-PostScript printer format), as soon as is ready to be received.

Sophisticated installations may involve user authentications, print quota, job prioritizations and more. All this is handled by the spooler and does not need any specific user attention, once your printers are correctly installed.

If you are sure about any correction or addition you may want to make, feel free to edit this Wiki directly. If you want to discuss it first, write to Kurt Pfeifle (kpfeifle AT danka DOT de).