From owner-freebsd-questions@FreeBSD.ORG Mon Sep 20 17:18:48 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0050B1065670 for ; Mon, 20 Sep 2010 17:18:47 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (ns2.r-bonomi.com [204.87.227.129]) by mx1.freebsd.org (Postfix) with ESMTP id B44718FC1D for ; Mon, 20 Sep 2010 17:18:47 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.3/rdb1) id o8KHGpxf013791 for freebsd-questions@freebsd.org; Mon, 20 Sep 2010 12:16:51 -0500 (CDT) Date: Mon, 20 Sep 2010 12:16:51 -0500 (CDT) From: Robert Bonomi Message-ID: <201009201716.o8KHGpxf013791@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 17:18:48 -0000 > 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 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. , , 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.