MFC 7840W under CUPS

[Da Rock]

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.