Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Feb 2012 00:10:43 +1000
From:      Da Rock <freebsd-questions@herveybayaustralia.com.au>
To:        freebsd-questions@freebsd.org
Subject:   Re: MFC 7840W under CUPS
Message-ID:  <4F3E5FE3.8070100@herveybayaustralia.com.au>
In-Reply-To: <4F3E572D.6060502@herveybayaustralia.com.au>
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> <4F3E572D.6060502@herveybayaustralia.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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....



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3E5FE3.8070100>