Both EFI and Onyx are good choices. A good PPD/driver for the RIP should not leave you with fewer device control features as does the manufacturer's driver, usually though they are called by different names or managed under different buttons. In some cases, you may lose drying time (but not often) and some "status" stuff at the client level (that's what the RIP management tool is for, so a lot of that gets offloaded from the client).
I can't think of any distinct disadvantages. I've been in environments with mid- to high-end poster printers in the past (from in-house print shops to service bureaus) and they've all used RIPs to get the job done. It just makes it easier to manage (workflow, workload, and color management).
I have a similar scenario as Gene. We have a Mac photo lab running 8 R3000 Epson printers, as well as a 9900 and 4900. I have used a RIP to manage printers comparable to the Epson 9900 in a commercial printing environment, so I agree with the benefits of control over color profiles, as well as having better workflow. For the larger Epson's I can see a RIP as the solution.
My biggest issue is how to manage the smaller R3000 Stylus Pro printers where the photo department wants a direct printing environment. I have a popup client direct printing to the Xerox 770 using CWS, but don't have a way to test the R3000's. Are there any schools currently using RIP software to manage Epson stylus pro printers with direct printing?
2 of 2 people found this helpful
Ah..."CWS"...there's an acronym I've not had to utter in a very long time. I remember when the XJ series first came out. Sigh.
So enough of the nostalgia. It's perfectly fine to manage things in a direct print environment with a RIP. Since you have good Fiery experience, I'll use that as a reference:
- Use the client PostScript driver to create the Queue on the Uniprint server.
- Convert/Specify it into a Direct queue. This will also be your reference queue for your Pharos Popup package.
In Uniprint 8.2 and lower:
- Create the Device queue as would be done if this was a client PC:
- Create a Standard TCP/IP connection to the RIP as LPR. Reference the RIP's IP address as the printer IP address, use LPR as the Protocol, and specify print as the LPR Queue Name. Enable byte-counting (this setting allows a non-Windows LPD implementation to accept the LPR job). if you're using a non-Fiery RIP, specify the queue's share name as the LPR Queue Name, ensuring first that the LPD protocol has been installed on the operating system.
- Bind it to the Queue.
In Uniprint 8.3 and greater:
- Insert a new Device.
- Specify the RIP's IP address as the printer address.
- Specify print as the LPR Queue Name.
- Disable SNMP State Check.
- Add it to the same Print Group as the Queue.
I hope this helps.
Thanks for the setup info! The way I am currently using the direct print queue is slightly different.
I will be trying this method with different RIP software demos to see which one gives us the best results.
Hi Scott and Lloyd,
Thanks for the followup questions and answers! We'll be doing some RIP demos too, and keep the group updated on what we find.
We are at University of Toronto Faculty of Architecture using Onyx to RIP jobs for Epson and HP plotters (4900 is kinda a small plotter :-))
But our experience with Pharos page counter (multipage postcript jobs with sizes ranges from 50mb to 300mb) was mediocre, so we end up with custom build web submission interface to format jobs for further accounting and post rip-process log analyzer which charges back to Pharos users based on what in what amount they printed... Can't say it is perfect, but permit to operate devices 24/7 without supervision and recover costs that are not small - from $50 to $200 per job (couple meters of 44" wide Epson output) :-)