Making use of printers is currently the weak point of most POSIX
systems (ironic, considering Unix's initial commercial application
was typesetting). The Free Software Foundation realized that the
GNU system needed a printing subsystem, so they approached Ben
Woodard to help fill this gap. A full description of this system
and its future development can be found at the gnulpr homepage.
Currently, the standard is LPR. LPR was a quick hack written
to meet a DARPA deadline in 1983. It is insufficient for today's
printing environment, and development has stalled completely. Some
have tried to replace it, with mixed success. We are planning to
take over new development of LPR, with the aim of smoothly
graduating to a more advanced system.
Gnulpr 1.0 will be the "anthology release". It is a compilation
of all of the various pieces that go together to make a proper
printing system, including a graphical client and a set of
printfilters. This release also includes job status notification,
and device-specific feature handling via PPD files.
Gnulpr 1.1 will include the initial steps toward a client
library for applications to use in managing print jobs. Future 1.x
releases will work toward finishing and completing this library and
Gnulpr 2.0 will be a radical departure from the architecture
currently used by LPR, while retaining a familiar interface for
those who need it. While the gnulpr 1.x series is based upon the
old BSD lpd spooler, gnulpr 2.x will have a brand new spooler.
Gnulpr 2.0 is a much more modular design, focusing on simplicity,
security, and flexibility.
The network daemon will be one program, the local job submission
daemon will be another, the network transmission filter will be
another, etc. Each utility will Do One Thing And Do It Well, and
the addition of a new network protocol or spooling policy is merely
a matter of implementing a few new utility programs.
Features of the gnulpr 2.x architecture include:
A design in accordance with the Software Tools philosophy.
A job submission API focused around the familiar (and
well-defined) behavior of the file descriptor, with helper
functions for applications that do not wish to deal with the
details of managing the descriptor.
The ability to do away with on-disk spooling, for those who
need to keep printer input performance at maximum.
The ability to easily install a custom spooling policy, for
installations with complicated queueing requirements.
Network protocols are handled by standalone client filters, as
well as daemons that use the client library to submit print jobs
received from remote hosts.
Modular data stores for printer enumeration, allowing
/etc/printcap, LDAP, or any other data access method to be
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.