[lug] Inexpensive Laser Printer (a quick review)

[J. Wayde Allen]

On Sun, 30 Sep 2001, Rob Riggs wrote:

> Installing this printer gave me a glimpse of one of the uglier aspects 
> of Linux (and Unix in general). There is no standard printing subsystem.

Printing under *nix always seems to be an issue.  I have to admit that it
took me several days to figure out printing under Linux the first time
around.  The problem is that I'm not sure what should be done, if
anything.  So ... this seems like a really valid topic for discussion.

Not intending to be too pedantic, I know that Rob probably knows more
about this than I, I'm thinking it might be worth digging back into the
design philosophy for Unix.  Rather than me typing a lot here, it would
probably be instructive to refer everyone to the "newbie" columns I was
writing several years back.  These can be found at
<http://lug.boulder.co.us/docs.html>.

The key issue has always been that *nix has tried NOT to embed hardware
specific code into the general OS software.  Designers have always striven
to keep hardware specific features at the kernel level and the kernel is
supposed to allow each device to be accessible to the higher level OS
structure as simple files.  File contents are handled by the higher level
programs.  The idea has been to minimize the coding required to adapt a
new piece of hardware to the system.  After all, Unix was invented at a
time when computer hardware was far less standard than it is today.

The printing subsystem, if I understand what is meant here, would then be
the lpr command.  This allowed one to specify the low level printer
characteristics such as where the printer is located (parallel, serial, or
network port), its name, and how to talk to it.  You'd then send print
jobs to the printer of your choice using:

   lpr -Pprinter_name file_to_print

You could also send a print job to the printer directly by typing

   cp file_to_print /dev/printer

,but the lpr command in concert with lpd was designed to handle print
spooling etc..  This subsystem provides the mechanism and logistics for
getting the file you want to print to the appropriate printer, and since
it doesn't care about the file contents should work for any kind of
printer you'd care to use.  It was left up to the user, and/or the program
creating the print file to create a file of the type that the printer
could understand (ASCII, PCL, Postscript, etc.)  My guess is that it is
this last point where most of the problems lie.  You can't just send a
binary file to the printer without first converting to a format the
printer understands.

Here is where things get a bit sticky.  In MSDOS/MSWindows you have the
so-called device driver.  This is philosophically a bit different that a
kernel module in Linux since the driver contains both the hardware
interface code, and often the data conversion code.  In Linux the idea
with the lpr command is to use data "filters".  Filters are supposed to be
the code that converts one specialize file format into the language that
the printer recognizes.  You can write your own, and/or find these filters
on the net.  The lpr command has a series of filter identifiers
(c,d,f,g,l,n,p,t,v) that specify which filter should be used.  Some of
these may be hard coded in the lpr specification, but as memory serves you
have to specify the path to the filter location associated with each of
these letters in the /etc/printcap file along with the printer
description.  I think that lpr is "old" in the sense that there are only a
limited number of printer filter identifies.  However, there has been a
solution.

When building the printer description in the /etc/printcap file one
specifies the default filter to be used when no filter option is
specified.  Then what has typically been done is to write this default
filter so that it can read the magic numbers out of the printer files and
decide what if any conversion needs to be done.  These filters are usually
called "magic filters" and eliminate the need for the user to know what
kind of file conversion needs to be done.

The advantage in this kind of world is that programs that want to print
somewhere don't need to know anything about the printers.  They simply
need to create a file that is understood by the magic filter and to send
their output through the lpr print subsystem.

> Samsung has to provide seperate packages and give seperate instructions 
> for every major distribution. There is no way to distribute a seperate 
> ghostscript driver (ghostscript device drivers are all compiled into a 
> monolithic program). These problems have to be addressed if we are to 
> ever see better printer support under Linux.

This is unfortunate, and I wonder if it is caused by approaching this as a
printer "driver" problem?  If they used the *nix philosophy it should be
relatively simple to create a kernel module with the minimum code needed
to talk to the device.  Then they'd only need to build a magic filter
designed to print standard file formats (ASCII, JPEG, TIFF, Postscript,
PCL, etc.).

My guess is that there are actually several issues:

   - Misunderstanding the *nix design philosophy and treating this as
     MSWindows style driver

   - Use of non-standard, proprietary printer languages

   - Confusion about just where these files should go in a distribution

Of course, I may also have just completely missed the point.  In any case,
printing is a common topic with some serious stumbling blocks that should
probably be discussed.

- Wayde
  (wallen at lug.boulder.co.us)