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... :)
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
