Date: Mon, 20 Sep 2010 12:16:51 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer Message-ID: <201009201716.o8KHGpxf013791@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Mon Sep 20 07:11:41 2010
> Date: Mon, 20 Sep 2010 05:20:52 -0700
> From: perryh@pluto.rain.com
> To: FreeBSD@insightbb.com
> Cc: freebsd-questions@freebsd.org
> Subject: Re: The nightmarish problem of installing a printer
>
> Steven Friedrich <FreeBSD@insightbb.com> 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
it.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009201716.o8KHGpxf013791>