From owner-freebsd-questions@FreeBSD.ORG Fri Feb 17 13:38:21 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 A3A4B1065670 for ; Fri, 17 Feb 2012 13:38:21 +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 1BDEF8FC13 for ; Fri, 17 Feb 2012 13:38:20 +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 A37795C22 for ; Fri, 17 Feb 2012 23:51:46 +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 D869B5C2B for ; Fri, 17 Feb 2012 23:51:45 +1000 (EST) Message-ID: <4F3E572D.6060502@herveybayaustralia.com.au> Date: Fri, 17 Feb 2012 23:33:33 +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> In-Reply-To: <20120217141447.b99dda33.freebsd@edvax.de> 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 13:38:21 -0000 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.