Date: Fri, 17 Feb 2012 23:33:33 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: MFC 7840W under CUPS Message-ID: <4F3E572D.6060502@herveybayaustralia.com.au> In-Reply-To: <20120217141447.b99dda33.freebsd@edvax.de> References: <fc3bb6c7b4bf770606b95d2514e8863a@mail.a4a.de> <20120211231729.d4ad2f8d.freebsd@edvax.de> <20120212083327.0a3b5c52@scorpio> <4F37CBC2.7060609@herveybayaustralia.com.au> <20120212100038.412369e7@scorpio> <20120217141447.b99dda33.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3E572D.6060502>