The nightmarish problem of installing a printer

Robert Bonomi bonomi at
Mon Sep 20 17:18:48 UTC 2010

> From owner-freebsd-questions at  Mon Sep 20 07:11:41 2010
> Date: Mon, 20 Sep 2010 05:20:52 -0700
> From: perryh at
> To: FreeBSD at
> Cc: freebsd-questions at
> Subject: Re: The nightmarish problem of installing a printer
> Steven Friedrich <FreeBSD at> wrote:
> > > "Common Unix Printing System" certainly sounds as if the intent
> > > was to be the "ONE thing that is used for printing".  Whether
> > > they did a good job of it is another question entirely :(
> >
> > I think that you don't fully apreciate the task at hand.  When
> > Unix was first invented, there were no laser printers, ink jets,
> > USB, etc.
> >
> > That no one can create a one-size fits all solution OWES to the
> > fact it's simply not always possible to unify disparate designs.
> > They weren't designed to be interoperable.  Technology keeps
> > marchng forward. We need to discard all of it eventually.
> Back in the CP/M and early MS-DOS days, similar doubts were raised
> regarding display systems.
> Fortunately, those doubts did not stop some developers from doing
> what others thought impossible.  The results included X11, which
> has been rather durable for a considerable time.

<snort>, <snicker>, <gasp> ROTFLMAO

"X" works IF AND ONLY IF you have:
   1) software that uses and  responds to the *PUBLISHED* protocol for 
      communicatins between applications and servers
   2) a server that _knows_ how to communicate to the actual display device.
      either because that device behaves in compliance with a PUBLISHED
      specification, or because somebody who 'knows the secrets' has provided

There has been an *EXACTLY* EQUIVALENT solution for printers for more than
two decades.  It's called "PostScript".

The problem with supporting modern "WinPrinters" is that a signficant amount
of the 'smarts' necessary to produce a printed page are *NOT* in the printer.
they are on the 'driver' that the printer manufacturer supplies (and only as
MS-WINDOWS(r) code).  They 'know the secrets' (see #2 above), of how to talk
to the stupid hardware, and provide a 'standard interface' (the windows device
driver) on the 'upstream' side of that software.

Unfortunately, that is the *only* interface THEY provide -- you can't talk
PostScript to it, you can't talk PCL to it, you cant talk "X" to it, you
can't even talk "Plain ASCII" to it. 

Since _nobody_else_ "knows the secrets" of how to actually communite with
that stupid hardware, we _CANNOT_ write a driver to use the device, no 
matter how much we would like to.  *UNLESS* the manufacturer releases the
protocol info (see #2 above) for direct device communiction, that is.

Some hardware 'speaks' a "standard' language, and is plug-and-play 
interchangable with any other device that speaks the same language,
without *ANY* changes (not even a different 'device driver') to whatever
it is connected to.  As long as the connecting device has *a* driver
tat supports that standard.

Hardware that speaks a 'proprietary' language requires a 'customized'
driver on the host system -- one that knows how to translate from 
the format that applications use to what the printer understands.  

*IF* the proprietary language is _documented_ -- i.e. =published= (see #2m
above) -- then *anybody* with an incendive to do so *CAN* do so.

*WITHOUT* such documentation, from *somewhere*, we are simply =unable=
to do the things necessary to utilize that printer.  No matter _how-
'attractive it is.

"Adapting"  MS-Windows print drivers is not 'practical' either.  A windows
print driver is embedd in the O/S KERNEL,  with _system_ calls_ (not 
mere 'library' routines) that implement the 'device-dependant' rendering
of layout/formating directions.  One then takes the 'opaque object' so
produced and sends it (via _another_ set of system calls) to the 'output'
function of that same driver.

In the Unix world, printing is handled _externally_ to the kernel. The
application must have =its=own=means= of deciding what formatting/layout
commands to use -- it _can't_ query the O/S for this info; the O/S simply
doesn't have it.

More information about the freebsd-questions mailing list