Re: RIps v. Epson driver
Re: RIps v. Epson driver
- Subject: Re: RIps v. Epson driver
- From: robcrow <email@hidden>
- Date: Tue, 12 Feb 2008 15:40:05 +0000
- Thread-topic: RIps v. Epson driver
Hi Stanley
>I would like to ask the list if anyone is successfully using OSX Server Print
> Services for the functionality that is normally associated with a RIP
I use OSX server queues to manage sharing 10 Epson 4800's a 7800 and a laser
printer to over 40 workstaions (Photoshop).
In terms of queue management you can do alot with the basic OS and OSX
server but not everything, which is why I am currently implementing a RIP.
The main problem with not using a RIP (in my case), is that it leaves users
in charge of the driver whereas a RIP allows me to offer them a simplified
experience while the complex settings are handled behind the scenes.
RIP features like linearization and nesting and are also not available in
the OS. (Hotfolders one could probably script with 'folder actions')
There are some other issues with print services (in Tiger at least) which
may or may not bother you...
Some of the abilities of Workgroup Manager (assigning users/groups/quotas)
do not work with printer pools or with some non-Postscript printers (unless
they are server attached via USB).
There is no way to list all jobs going to all printers on a single screen in
the print services GUI as there is in some RIPS (you can see all the info
just not all at the same time) and Individual queue windows do not show user
info (All this info is in the logs and a clever bit of scripting could make
use of it)
Some people report that print quotas are unreliable or have problems
implementing them (I use Papercut for this)
My current (non RIP) set-up...
Most of the clever stuff like printer pooling and implicit classes (which
allows printer pooling across different servers) is handled by CUPS and is
common to the standard - non server - OSX. Pooling is very useful - I have
multiple printers assigned to a queue and the job goes to the first
available printer. I am running Tiger but Leopard uses the latest version of
CUPS which also allows moving jobs from one queue to another.
I use Papercut http://www.papercut.com/ for auditing usage (and charging
users) this also gives detailed usage info and allows setting up of release
queues where jobs are held until admin releases them.
Printwatcher (which comes with the Epson printers) gives detailed info about
ink and paper usage as well as visual info about ink / paper levels etc
(it's a bit flaky but it works)
The OS CUPS page logs give other useful info.
My ideal set-up would handle all the queue management chores then hand the
job over to the Epson driver to print but the current driver stubbornly
refuses to be automated by all but the clumsiest GUI scripting. I am still
working on this, in the meantime I am putting a in a RIP.
Feel free to email me off list if you need any more info
Rob.
On 11/2/08 18:07, "Stanley Smith" <email@hidden> wrote:
> Mike-- your conclusion confirms what I've long suspected, but not really
> tested myself-- that the Epson drivers are superior to most RIPs.. We use
> RIPs here only for workflow purposes (Onyx), and they have proved to be
> difficult to maintain. I'm wondering if our gain in workflow benefits are
> really worth it-- mostly we just need to be able to manage the queue and
> linearize the printers for consistency.
>
> I would like to ask the list if anyone is successfully using OSX Server Print
> Services for the functionality that is normally associated with a RIP-- queue
> management, security, logging use, etc. A cursory look at Apple's guide for
> OSX Server seems to suggest that this functionality is there, but is anyone
> using this in lieu of a RIP? Do we really pay a price in productivity using
> the Apple services? I ask, because I am ready to dump Onyx in favor of
> something a little less convoluted and tortuous, but not really wanting to
> spend the dollars or time necessary of going to a high-end RIP solution such
> as GMG....
>
>
>
> Stanley Smith
> Manager, Imaging Services
> J. Paul Getty Museum
> 1200 Getty Center Drive, Suite 1000
> Los Angeles, CA 90049-1687
> (310) 440-7286
>
>
>>>> Mike Strickler <email@hidden> 2/8/2008 8:50 PM >>>
>>
> Rob,
>
> Let's try to parse these issues a bit first. The allocation of light
> v. dark inks is a function of the driver, whether the Epson stock
> driver or one used in a RIP, and not a function of the profile, which
> nothing of how the printer combines inks to make the primaries. So we
> can hold Profilemaker harmless for any problems there. Epson has
> already dialed in the right formula to give a smooth transition from
> light to dark inks; sometimes this needs to be adjusted in the RIP,
> assuming that the RIP allows the user to change this. Black
> generation is an area of great importance in maintaining neutrality.
> Here nominally neutral combinations of C, M, and Y are replaced with
> black ink to give more stable gray balance and reduce total ink. This
> is handled inside the Epson driver in the conversion of RGB to CMYK.
> When RGB files are sent to a RIP, however, this black replacement is
> normally handled by the printer profile, and here Profilemaker and
> Monaco Profiler give user control. (You'd be well advised to use an
> extremely aggressive GCR, even "Max K", with a black start of
> something close to zero). In the end the results using the Epson
> driver with the right media settings (these control ink limits and
> linearization) and a well made RGB profile and those made with a
> properly set up RIP and CMYK profile are very similar, but the latter
> depends on adequate controls within the RIP and some knowledge on the
> part of the user. Sometimes one can download complete "print
> environments" with ink limits, linearization files, and profiles for
> the paper one is using--and often not.
>
> My advice: Unless you have a really good RIP that linearizes properly
> (GMG, EFI, ORIS, Ergosoft, and Caldera come to mind) and you have
> someone who can set it up properly, the Epson driver and a good
> profile will probably give better results. You'll pay a price in
> productivity, but that's a trade-off you'll have to evaluate.
>
> Mike Strickler
>
> MSP Graphic Services
> 423 Aaron St. Suite E
> Cotati, CA 94931
> 707.664.1628
> email@hidden
> www.mspgraphics.com
>
>>
>> ------------------------------
>>
>> Message: 11
>> Date: Thu, 07 Feb 2008 10:08:13 +0000
>> From: robcrow <email@hidden>
>> Subject: Will my RIP ever produce photographic output to beat the
>> Epsondriver?
>> To: email@hidden
>> Message-ID: <C3D0890D.216C%email@hidden>
>> Content-Type: text/plain; charset=US-ASCII
>>
>> I am running Proofmaster RIP on a number of Epson 4800's and have
>> noticed
>> that with the current profile the neutrals are less neutral with
>> the rip
>> than with Epsons driver (they are slightly green). PM seems to use
>> less of
>> the light blacks than Epson in their provided profile.
>>
>> I am fairly new to CMYK profiling but am prepared to put in the hours
>> building custom profiles if I can produce a photographic output to
>> rival or
>> beat that from the Epson driver. Is it just a matter of plugging
>> away it? Or
>> are there things done by Epson in the driver that I will not be
>> able to
>> control with PM? (For example Epson's Advanced black and white mode
>> lays
>> down almost no colour ink at all).
>>
>> Any advice gratefully received
>>
>> Rob.
>>
>>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Colorsync-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Colorsync-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden