Date: Sat, 18 Feb 2012 00:22:09 +1000 From: Da Rock <freebsd-questions@herveybayaustralia.com.au> To: freebsd-questions@freebsd.org Subject: Re: MFC 7840W under CUPS Message-ID: <4F3E6291.3070409@herveybayaustralia.com.au> In-Reply-To: <20120217145738.f211687f.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> <4F3E572D.6060502@herveybayaustralia.com.au> <20120217145738.f211687f.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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... :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3E6291.3070409>