From owner-freebsd-questions@FreeBSD.ORG Fri Feb 17 14:15:31 2012 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 12ABE1065673 for ; Fri, 17 Feb 2012 14:15:31 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDD08FC08 for ; Fri, 17 Feb 2012 14:15:30 +0000 (UTC) Received: from mail.unitedinsong.com.au (bell.herveybayaustralia.com.au [192.168.0.40]) by mail.unitedinsong.com.au (Postfix) with ESMTP id D5B385C28 for ; Sat, 18 Feb 2012 00:28:55 +1000 (EST) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 271F65C22 for ; Sat, 18 Feb 2012 00:28:55 +1000 (EST) Message-ID: <4F3E5FE3.8070100@herveybayaustralia.com.au> Date: Sat, 18 Feb 2012 00:10:43 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <20120211231729.d4ad2f8d.freebsd@edvax.de> <20120212083327.0a3b5c52@scorpio> <4F37CBC2.7060609@herveybayaustralia.com.au> <20120212100038.412369e7@scorpio> <20120217141447.b99dda33.freebsd@edvax.de> <4F3E572D.6060502@herveybayaustralia.com.au> In-Reply-To: <4F3E572D.6060502@herveybayaustralia.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: MFC 7840W under CUPS X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-questions@freebsd.org List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 14:15:31 -0000 On 02/17/12 23:33, Da Rock wrote: > On 02/17/12 23:14, Polytropon wrote: >> On Sun, 12 Feb 2012 10:00:38 -0500, Jerry wrote: >>> It appears that "ps" is no-longer the format of choice but is being >>> replaced by PDF, a format that is natively supported by many printers. >> Jerry, I wanted to point out that PS still seems to be the >> format that _applications_ use as output format for printing. >> Even though especially office applications (such as Abiword >> or LibreOffice) have a built-in PDF file generator, the printing >> output that is sent to the printing subsystem (lpr, CUPS, whatever) >> is in PS format and gets converted to what the printer needs >> by the proper printer filter ("driver"). >> >> The "print to file" output method typically creates PS, at >> least on UNIX, Linux, MacOS X and other operating system >> families. >> >> If printers would natively support PDF data instead of unknown >> arbitrary commands to move the printing head - things would be >> MUCH LESS complicated on the OS's side. Data just needs to be >> generated in PDF natively, or converted from PS to PDF (simple >> task) by the printer filter, and then just sent to a specific >> network address (just as netcat could do). That would nearly >> eliminate the need for printer drivers I think. The only thing >> that comes to my mind is... how does it handle duplexing and >> other printer-HARDWARE specific things? Can they also be "coded" >> in a PDF file? >> >> Really, I like the approach of having PDF as a universal "printer >> language" (even though it's not 100% safe from a security point >> of view, but that doesn't matter on the home consumer market >> anyway). It would remove any need complicated things like (in >> my opinion) the CUPS configuration. You just need to enter the >> IP of the printer - done; and it doesn't even matter of this >> is a wired or wireless connection! Maybe even lowest-end USB >> devices can accept a PDF "data stream"... >> >> Think about that: >> >> % netcat 192.168.123.456< /tmp/printing.pdf >> >> or even >> >> % cat /tmp/inkpee.pdf> /dev/ulpt0 >> >> to make the printer start printing... >> >> With standardized PDF "instructions", there would be no need >> for artificial OS barriers. PDF is known. No need to port any >> drivers, to create wrappers or jump though hoops. >> >> Note that the system's DEFAULT printing facility (the printer >> spooler) would be a perfect means to plug in. Printer "filters" >> could be easily implemented, i. e. only _one_ filter needs to >> be present: one that converts an application's PS to PDF and >> the send it to the printer's local port or IP address. All the >> parts needed for that task are already present (and have been >> for many years). >> >> Would be interesting to see how this develops. Thanks for sharing >> that info, sounds really good. > PDF is not exactly PS, but it does use a subset of the instructions. > As near as I can tell this is how they're using it, as it is only 1.7 > or so onwards. > > The other thing you will notice is that its mostly on MFC's, so I > believe they're using the PS chipset to encode a scanned doc to PDF; > I'm not sure it works the other way around, and I may even be wrong > about what they're doing but I think it is very suspect. > > A PS chipset is only an interpreter - it cannot normally encode PS, > only read a PS stream and rasterise it. But they may have extended it > in only this case. As for printing PDF, maybe... time will only tell. What I forgot to add is that it would be no more difficult to print PDF as it is to print PS - you'd use the same functions but a slight difference in the quantity of data. I have yet to see a printer that will do it though....