From owner-freebsd-questions@FreeBSD.ORG Fri Feb 17 13:14:50 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 EDB2B1065675 for ; Fri, 17 Feb 2012 13:14:49 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by mx1.freebsd.org (Postfix) with ESMTP id AB60E8FC12 for ; Fri, 17 Feb 2012 13:14:49 +0000 (UTC) Received: from r56.edvax.de (port-92-195-127-244.dynamic.qsc.de [92.195.127.244]) by mx02.qsc.de (Postfix) with ESMTP id CDDEF1E307 for ; Fri, 17 Feb 2012 14:14:47 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id q1HDEln4010576 for ; Fri, 17 Feb 2012 14:14:47 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Fri, 17 Feb 2012 14:14:47 +0100 From: Polytropon To: FreeBSD Message-Id: <20120217141447.b99dda33.freebsd@edvax.de> In-Reply-To: <20120212100038.412369e7@scorpio> References: <20120211231729.d4ad2f8d.freebsd@edvax.de> <20120212083327.0a3b5c52@scorpio> <4F37CBC2.7060609@herveybayaustralia.com.au> <20120212100038.412369e7@scorpio> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 13:14:50 -0000 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. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...