Date: Tue, 21 Sep 2010 19:17:44 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: bonomi@mail.r-bonomi.com, cpghost@cordula.ws Cc: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer Message-ID: <201009220017.o8M0HiZS024365@mail.r-bonomi.com>
next in thread | raw e-mail | index | archive | help
> From cpghost@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@cordula.ws> > To: Robert Bonomi <bonomi@mail.r-bonomi.com> > Cc: freebsd-questions@freebsd.org > > On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi <bonomi@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.`
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009220017.o8M0HiZS024365>