Printing Software
 by Grant Taylor, in Category Reviews - Sat, Sep 15th 2001 00:00 PDT

To print something from a Free Unix, you use an application, which uses a client program to speak with a daemon process, which eventually executes some sort of driver or filter, which eventually sends print data to your printer. There are no universal standards for any step in this process; indeed, in many installations, hand-tooled scripts provide the glue between the various parts. This makes for a rather unpleasant configuration experience, to say the least.

In this review, I'll describe the most popular programs used at each stage in the printing process. Describing how to integrate any of them into any particular printing setup is way beyond the scope of this document; see the program's documentation or the Printing HOWTO for more information.

Devices

All printers are connected to your computer through a device of some sort. The most popular device is perhaps the parallel port, but USB is now quite common. Beyond local device connections, a wide variety of protocols can be used to send print jobs over the network to a printer.

Parallel, USB

For local devices, you just need to determine the proper device name and make sure that your kernel contains the proper driver. Typical device names include /dev/lp0 and /dev/usb/lp0.

LPD

The LPD protocol (not to be confused with LPD software) is the most common network printing protocol on Unix. Frequently, it can also be used to submit jobs to network-connected "Ethernet" printers or standalone print servers. If you need a standalone LPD client for scripting (or interactive!) purposes, use rlpr.

IPP

The new Internet Printing Protocol is a modern printing protocol built atop MIME and HTTP. It is implemented by CUPS, Windows, and a few other systems.

AppSocket

The so-called "appsocket protocol" is nothing more than print data stuffed through a TCP connection. If you need to send print data this way, use the program nc, aka NetCat. Many spoolers (CUPS, LPRng, etc.) include native support for this.

Novell

If you need to print to a Novell network printer, the ncpfs suite includes a printing client program.

Windows

If you need to send jobs to a Windows server, the Samba suite includes a client utility.

Apple

If you need to print to a networked Apple printer, the Netatalk distribution includes a client program.

Drivers

Drivers are probably one of the most active areas of development these days. The best modern Free Software drivers produce quality that rivals or even surpasses that from vendor-provided drivers. Given the software-centric and highly complex nature of modern printing, this is no small accomplishment.

To be useful for general-purpose work, all drivers must interoperate somehow with the de facto standard RIP Ghostscript. Ghostscript converts Postscript data into printer-specific data; drivers basically perform the bottom half of this task.

Usually, a filter package is used to glue the driver together with the spooler, and to preprocess print jobs in various ways. Popular filter packages include magicfilter, apsfilter, and foomatic.

Laser Printers

Most mid-range and up lasers include native Postscript support, so they really don't need much of a driver. Many personal-sized lasers, however, speak PCL or another proprietary language, and require drivers. For most of the PCL devices, the selection of standard drivers in Ghostscript does the job; the ljet4 driver is the workhorse of the bunch, but there are several others. All are included in any sensible Linux distribution's standard Ghostscript.

Inkjet Printers

Here's where it gets interesting. Inkjet print quality is largely influenced by the software used to drive the printer. The gimp-print project has produced a driver suite that drives most Epson Stylus and many other brands of color inkjet printers. The output quality on properly-supported devices gives Epson's software group a run for their money.

Also of note are the HP-provided hpijs inkjet drivers for DeskJets. They're simpler than the gimp-print system, but they do work quite well on the DeskJets. The license is not free, but not very far off; you certainly get the source and the right to modify it.

OMNI

Also interesting is IBM's OMNI driver system, ported from OS/2. IBM provides quite good support for a wide array of devices. The architecture is mature and data-driven; look for interesting development to happen here.

Where to find drivers

There are roughly 200 individual printer drivers in the world. Only a few distributions make any effort to ship them all, so there's likely to be a driver for you out there even if your printer isn't supported by your distribution. A good index of printer drivers for Free Unix users is the database at LinuxPrinting.org.

Spoolers

There are several major and as many more minor print spoolers for Unix. Most distributions ship several, but steer you toward one which they support (i.e., Red Hat with LPRng and printconf, Mandrake with CUPS and KUPS, etc). Among the more popular spoolers are:

LPD

LPD, or Line Printer Daemon, is the traditional Unix spooler. As the name suggests, it was originally implemented to support text-only line printers, but with a bit of scripting, it can usefully manage modern print jobs. Most LPDs out there tend to have security problems, usability problems, or both; major Linux distributions are moving away from traditional LPD in favor of other spoolers.

LPRng

LPRng, by Patrick Powell, is a more powerful reimplementation of the basic LPD daemon. Many additional job control and security features are available. Several distributions, including Red Hat, ship this as the core of the primary printing system.

CUPS

CUPS, or Common Unix Printing System by Michael Sweet, is a fairly new spooler designed around the IETF Internet Printing Protocol (IPP). CUPS is quite featureful, compared to LPD-style systems. It especially includes many features leveraging the fact that most print jobs on Free Unix are either submitted as PostScript or rendered via PostScript or both. Many distributions now ship CUPS as the default printing system.

PDQ

PDQ, or "Print, Don't Queue" by Jacob Langford, is a fresh take on the whole problem; it doesn't really spool at all, but instead merely processes print jobs and sends them to the printer immediately. A simple configuration format incorporates all the necessary scripts, metadata, etc.

PPR

PPR is a Postscript-centric system written for use at Trinity College.

User Interfaces

These are programs which make it easier to submit a print job. Merely submitting jobs isn't hard, but modern drivers have many options, so having a GUI which lets you adjust printtime options is actually fairly important.

LPR

The lpr command is the de facto commandline interface for submitting print jobs. All software which can submit print jobs on your behalf can send jobs by running lpr. Bad software is limited to this; most software lets you specify an arbitrary command with options.

KDE

There are several client programs which fit into KDE. The latest is the KPrinter class by Michael Goffioul, which provides standard dialogs with support for a number of underlying print spoolers. Also available is the QtCups application, which presents a KDE-friendly interface to the CUPS system.

For configuration, the Qt program KUPS can configure printers in the CUPS system.

GNOME

GNOME also includes a standard printing dialog, and a GConf-based configuration system is under development by Chema Celorio.

Misc

XPP by Till Kamppeter is another nice GUI for the CUPS system. It's based on FLTK.

Applications

All of this is useless if you have no software to generate something printable. Here are some of the most popular packages for doing this:

Markup

Traditionally, Unix was often used for text processing. Most of the original Unix tools were markup languages like HTML. The most mature such system for producing printable output is undeniably TeX or LaTeX. Also available are a number of markup strains implemented atop Free SGML and XML tools, most notably DocBook.

WYSIWYG

These days, many people prefer a more visual package than vi or Emacs; several projects are designing regular word processors, including AbiWord, KWord, OpenOffice, and others. If MS Office interoperability is needed, the current choice is Sun's StarOffice, a no-cost commercial product. If merely a workable word processor is needed, KWord and AbiWord are both quite usable.

For bitmap graphics work, The GIMP is the package to use. It can use the gimp-print inkjet driver software directly for fine control over output quality.

Vector graphics can be done with Dia, XFig, or Kontour.

Filters

Free Unices are often used as servers. In this role, scriptable tools are extremely useful. psutils provides for fairly complex slicing and dicing of Postscript print jobs. Also available are such conversion apps as a2ps, enscript, htmldoc, and ImageMagick, Ghostscript and its PDF and Postscript processing companions ps2pdf, ps2ps, etc., and a host of other utilities. Together with the usual Unix scripting features, these provide ways to automate all sorts of printing tasks.

Conclusion

All things considered, desktop Linux users suffer from the somewhat disjointed system that passes for printing infrastructure on Unix. Various individual projects produce exceptional printing-related software, while vast swaths of "plumbing" logic simply don't exist. Driver quality varies widely. Interfaces are not standardized. User interfaces are often absent.

Fortunately, several players in the printing industry are working to improve this situation. For example, HP funds several development projects, Epson shares usable programming information, Easy Software develops the CUPS spooler, and Mandrake and Ximian experiment with packaging, integration, and user interface issues. The next few years should see interesting developments in all kinds of Linux printing.

Author's bio:

Grant Taylor runs LinuxPrinting.org and is the author of the Printing HOWTO. He works as a software developer in the Boston area.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Printing

Referenced projects a2ps - An any-to-PostScript filter. AbiWord - A fully-featured word processor. apsfilter - An intelligent line printer input filter. Common UNIX Printing System - An Internet printing system for Unix. Dia - A GTK2-based diagram drawing program, similar to Visio. DocBook - DocBook stylesheets, schemas, documentation, and resources. enscript - A tool to convert ASCII files to PostScript. Foomatic - A database for integrating printer drivers with every printer spooler. Ghostscript - An interpreter for the PostScript (TM) language. GIMP - GNU Image Manipulation Program. gnulpr - A printing system designed to graduate users from LPR. Gutenprint - Top quality printer drivers for POSIX systems. HP Linux Inkjet Driver Project - A Ghostscript addon for inkjet printers. HTMLDOC - A tool to convert HTML to indexed HTML, PostScript, and PDF. ImageMagick - A comprehensive package supporting automated and interative manipulation of imag KOffice - An integrated office suite for KDE. KOffice - An integrated office suite for KDE. KUPS - A CUPS administrator for KDE. LaTeX - A high-quality typesetting system based on TeX. LPRng - The Next Generation of LPR. Magicfilter - An extensible and customizable automatic printer filter. ncpfs - Linux tools for mounting and printing to Netware servers. netatalk - A kernel-level implementation of the AppleTalk Protocol Suite. netcat - A network piping program. OpenOffice.org - An Open Source version of StarOffice. pdq - A printing system. PPR - A print spooler for PostScript. QTCUPS - A CUPS frontend and development library for Qt. rlpr - A tool to print from remote sites to your local printer. Samba - Tools to access to a server's filespace and printers via SMB. StarOffice - A cross-platform office suite. teTeX - A TeX distribution for Unix. X Printing Panel - A graphical printing frontend for CUPS. xfig - A drawing program.

 Comments

[»] The high-quality printer driver solution for Linux!
by Ivan Gerasimov - Sep 21st 2001 02:39:14

www.turboprint.de TurboPrint makes it possible to use the latest color printers with Linux. It is designed to produce maximum quality photo prints as well as high-speed text documents. Printer set-up and configuration is as simple as on Windows or MacOS. TurboPrint benefits from more than 10 years' know-how and experience in printer driver development. "If you want to get the optimum out of your printer, TurboPrint is a real must" (German Linux computing magazine 3/2001)

--
I love Linux

[reply] [top]

[»] More printer drivers than 200
by Steve Fox - Sep 15th 2001 22:22:47

FYI...Omni alone supports over 300 printers

[reply] [top]

[»] And there are even goofier printing protocols still.....
by \lart - Sep 15th 2001 11:04:44

My printer, an HP LaserJet 2100M with a JetDirect 610N card installed even supports FTP for printing. That's right - you give me a PCL file, I upload it to my JetDirect card, and paper starts flying out of the printer, with stuff printed on it even.

I know, it's not the most useful thing, but it's neato. I did actually use it not long ago, when a cow-orker had a file in some horrible file format (I think it was M$ Works), so he printed to a file, and sent me the PCL. I uploaded it to the printer and got the doc. Frightening.

[reply] [top]

[»] It's up to the hardware developers to speed up Linux printing support
by Jonathan Thorpe - Sep 15th 2001 04:47:23

For many years, Linux has suffered greatly because of the lack of support from hardware developers. It's evident that this is in some ways preventing the further development of particular areas of Linux' progress as the "standard" operating system.

I am presently working for a firm working on Linux Distributions, and from my perspective, the inclusion of printer support has thus far been the toughest obstacle yet.

It's fine that the CUPS software that we're using works with a variety of printers, but for every printer we get working, there is at least one that has some sort of issue with compatability.

The lack of hardware support is widely because hardware vendors aren't prepared to move on from Windows-only support which is, in many cases causing significant problems.

Many printer vendors (we won't mention names here) are taking the trend toward host-based printing solutions, producing printers which use more software than hardware. This is fine if it works, but the issue is that developers aren't prepared to support Linux, and only in very few cases are they providing information to the Linux developers regarding their proprietary protocols used on these so-called "Winprinters".

Hardware developers, particularly in the area of printers need to take hold of the Linux OS and begin support. I'm sure if some printer manufacturers started shipping printers with vendor-provided Linux support, they'd have a very large market within the Linux software industry.

[reply] [top]

[»] Re: It's up to the hardware developers to speed up Linux printing support
by Tim Jansen - Sep 15th 2001 10:51:37

> The lack of hardware support is widely because hardware vendors aren't prepared
> to move on from Windows-only support which is, in many cases causing significant problems.

IMHO the problem is that no operating system makes writing drivers as hard as Linux, and this is not only a problem for printers. If you want to write a printer for that other OS you buy a book about WDM, download the DDK and write the driver. It will work for every user without much effort. If you want to write a printer driver for Linux you first have to chose which printing systems you want to support. Every system is different, and there is no compatibility standard. Assuming you have a driver for at least one printing system, you should provide RPMs. But for which distribution? You need one set of RPMs for each single distributions, and usually even for each version. In other words the effort for writing Linux drivers is huge compared to Windows. That Linux licenses often require the vendors to release the source code does not help much either...

[reply] [top]

---

[»] Re: It's up to the hardware developers to speed up Linux printing support
by simmons75 - Sep 15th 2001 19:30:11

% If you want to write a printer driver
> for Linux you first
> have to chose which printing systems
> you want to
> support. Every system is different,
> and there is no
> compatibility standard. Assuming you
> have a driver
> for at least one printing system, you
> should provide
> RPMs. But for which distribution? You
> need one set
> of RPMs for each single distributions,
> and usually
> even for each version.

Ignoring, of course, Slackware and Debian, which don't use RPM as the "native" packaging format. And this "analysis" of course ignores the *BSD world.

And also, of course, this "analysis" ignores the role of the distribution package maintainer.

If you want near-universal support for a printer, well man, I dunno. CUPS seems to want to become the universal print system, and why merely supporting it is such a bad thing is beyond me.

Even then, has anyone considered producing libs/proggys that would work with both CUPS and lpr/apsfilter?

[reply] [top]

---

[»] Re: It's up to the hardware developers to speed up Linux printing support
by Grant Taylor - Sep 16th 2001 22:16:51


> Even then, has anyone considered
> producing libs/proggys that
> would work with both CUPS and
> lpr/apsfilter? But of course!

Mandrake, Red Hat, Progeny, and probably several other distributions all ship default printing systems built atop Foomatic, which uses XML driver descriptions to make all drivers and most spoolers work together.

CUPS, LPRng, LPD, and PDQ should work with every free software printer driver on the planet using Foomatic. Bigger projects like Gimp-Print and OMNI ship Foomatic generator tools, while smaller drivers have simpler interfaces constructed by volunteers.

[reply] [top]

---

[»] Re: It's up to the hardware developers to speed up Linux printing support
by Grant Taylor - Sep 16th 2001 22:28:20


> Hardware developers, particularly in
> the area of printers need to take hold
> of the Linux OS and begin support. I'm
> sure if some printer manufacturers
> started shipping printers with
> vendor-provided Linux support, they'd
> have a very large market within the
> Linux software industry. It's beginning to happen. HP provides a driver kit replete with source (including their color code!), for the DeskJets, and they provide support (and a job) for the lead HPOJ developer. Epson provides reasonable specifications for their inkjets. Lexmark provides and supports binary-only driver kits for several inkjets. Indeed, of the biggies only Canon has no Linux story to date, at least for inkjets.

[reply] [top]

---

[»] One addition.
by piman - Sep 15th 2001 02:32:11

The HP OfficeJet series of printers (the All-in-One thingies) uses another driver, the <a href="http://hpoj.sourceforge.net">HPOJ</a> driver, part of which is a really neat library called PTAL (which makes 3rd party OfficeJet applications really easy, as my printer now displays how many messages are in my inbox instead of the year. :) It's (relatively) easy to set up, and is not shipping with most distributions yet (at least not out of the box). However, the drivers work great.

The drivers and the PTAL library are under the GPL, iirc.

[reply] [top]

[»] [PLUG] - Printbill
by Daniel Franklin - Sep 15th 2001 01:16:13

One other issue related to printing is the issue of billing or accounting for the actual cost of printing - to do this accurately you need to do more than just count pages. My printbill project uses ghostscript and some other goodies to give a fairly accurate estimate of the amount of toner used, and allows you to bill or just account for the amount used. Also works with colour, multiple print queues, is scalable, etc. etc... oh yeah and I'm currently testing version 3.1 which should fix all the existing bugs and add a bunch of new ones :)

[reply] [top]