MFC 7840W under CUPS
Da Rock
freebsd-questions at herveybayaustralia.com.au
Fri Feb 17 14:26:57 UTC 2012
On 02/17/12 23:57, Polytropon wrote:
> On Fri, 17 Feb 2012 23:33:33 +1000, Da Rock wrote:
>> PDF is not exactly PS, but it does use a subset of the instructions.
> That's correct, but both formats share essential parts of
> functionality. Conversion between them is relatively easy.
>
>
>
>> 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.
> Yes, PDF output of scanned documents (even multi-page ones)
> seems to be standard today (which is mostly a welcome solution
> for storing and re-printing scanned documents).
>
>
>
>> 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.
> I held a short lecture about PS many years ago. If I remember
> my own words correctly, the PS "circuit" in a printer is a
> little processor complex that processes the PS "programming
> language" to do rasterization (from vector data or embedded
> pixel objects), it could do calculations, some transformations
> (like rotation), some other functions (like repeating the
> output n times, use or not use the duplexer etc. depending
> on the printer's hardware). If this facility could be used
> to generate data and send it back through the network interface,
> or keep it in local storage so network access can "pick it
> up" (e. g. by FTP, NFS, CIFS/SMB), things would be easy as
> those mechanisms can be kept internally in the printer without
> requiring arbitrary "drivers" to make things work.
RIP processors do/did that. They're normally an external computer system
designed to do just that: act as a print server (sometimes a bit like
CUPS with a web interface) and you can store, hold, print jobs. Graphics
organisations still use them, but since processors are so fast these
days they don't always bother with some printers.
With these functions, the operator could receive a print job and direct
it to whatever printer was available/best suited and run it. Some used
them in the larger print shops for online printing from major contracts
to automate the processing of jobs (immediate/monthly/weekly, etc).
You could also send the ripped file (or a PS encoded one) anywhere you
want as well. The files were normally sent RAW and processed on the RIP
to whatever was needed or wanted, and there was PS on the machine. These
things were hooked up directly to the printer (no network - could be
though - just a scsi connection directly to the print engine) so they
had no real need for PS except to encode it.
The ones I worked on were NT based and some linux based ones. Fun
times... :)
More information about the freebsd-questions
mailing list