The nightmarish problem of installing a printer

[Robert Bonomi]

> From cpghost at cordula.ws  Mon Sep 20 19:40:36 2010
> Date: Tue, 21 Sep 2010 02:42:22 +0200
> Subject: Re: The nightmarish problem of installing a printer
> From: "C. P. Ghost" <cpghost at cordula.ws>
> To: Robert Bonomi <bonomi at mail.r-bonomi.com>
> Cc: freebsd-questions at freebsd.org
>
> On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> w=
> rote:
> > "Adapting" =A0MS-Windows print drivers is not 'practical' either. =A0A wi=
> ndows
> > print driver is embedd in the O/S KERNEL, =A0with _system_ calls_ (not
> > mere 'library' routines) that implement the 'device-dependant' rendering
> > of layout/formating directions. =A0One then takes the 'opaque object' so
> > produced and sends it (via _another_ set of system calls) to the 'output'
> > function of that same driver.
>
> Is that really so? How about writing some emulation shim like ndis(4) for
> winprinters? Please correct me if I'm wrong, as I'm not a Windows systems
> programmer, but this is what I'm thinking about.
>
> As far as I understand Windows printing, there are two aspects to resolve,
> given a vendor supplied windriver binary blob:
>
> 1/ the windriver gets some (opaque) data from the GDI+ -- maybe
> a bitmap, with some meta data.
>
> 2/ the windriver interprets this data however it sees fit, and then talks t=
> o
> the NT kernel (maybe via DLL calls) to send electrical impulses to the
> printer.

If only it _were_  sometine even approaching that simple!  Unfortunately, it
*isn't*.

*IF* UNIX applications produced their output in the form of gdi calls,
the approach you descibe _would_ be viable.  But they don't.  And therein
lies all the complications.

UNIX applications are almost entirely self-contained with regard to printing, 
A postscript producting app can make use of a printer-specific 'hints' file
that provides 'standardized' means of accessing printer features for which
'implementation details' are left up to the manufacurer -- e.g. paper source
tray 'numbering'; do trays start rom zero or one?  are they numbered 
consecutively? and which is which? (just for starter :)

Windows passes -individual- objects to the printer driver, which may return
a 'rendered' vesion _to_ Windows, which windoes ten merges with otheer 
rendered objects to produce next phase of the page which eventually goes 
through the driver a final time, and that bitstring is sent to the hardware.

If one has an application that "doesn't work that way", and autonomously
produces an output data stream of 'some' form,  there is a *MAJOR"* hurdle
in 'reverse engineering' that data stream back to 'objects' that can be 
fed to the Windows prinding model. as the manufacturer's printer driver
expects.  

If that isn't bad enough, there is no guarantee the the exact steps and 
sequences of operations that wee used to _produce_that data-strem, even
_HAVE_ a direct equivalent inthe Windows printing model.  (Heck this 
problem shows up _witin_ windows with different supported printers,
thats _why_ the applicationi has to adjust _its_ output logic to adapt
to the way the paritcular printer does things.o

When you're 'reverse engineering' from a set of concrete details to a set
of abstractions, *what*do*you*do* when you have a sequence of 'details'
that doesn't match _any_ of the possible abstractions in the target
environment?

Begin to get the idea?

Devloping the kind of 'shimp' you envision would be a significantly larger,
harder, and more time-consuming project than the development of Ghostscript.

and by the time the reqired team of engineers got through the years of work
involved, the chances are -very- good that nobody would be making 'that kind'
of printer driver any more. '95 drivers are not usablewith XP, XP drivers
are not compatible With Vista,  Vista <-> Windows 7,  I'm not sure about.`