1 of 1 people found this helpful
We run many Epson printers ... and they work great with Pharos ..... but you will need to use a RIP .... especially if you are using multiple operating systems in your labs ......
We use Onyx Production House, but I believe you can use ColorBurst which comes with the pro model of Epson 9880 ...
I appreciate the response. We have a fine arts lab that use iMacs running Lion. We are implementing Pharos in the lab so we can start charging students for their print jobs. The HP Plotter that they had went down and it is cheaper for us to purchase a new printer. They want to go with the EPSON 9890 and we just want to make sure it is going to work before we purchase it.
Thanks again for your input.
no problem .... actually in an environment that is only Mac, a RIP may not be required ... we have had some success making Pharos work with Epsons on Macs only.... Good luck!
3 of 3 people found this helpful
We in Pharos Technical Support get this type of question all the time, and we typically do not provide an answer that leaves a warm fuzzy. Before you ask "Why are they saying this?", let me give some background.
Printer drivers often support what I call a "client-server" function: I can install a driver on a Windows print server, share it, and then all of my Windows clients can simply connect to my share, download a local instance of the driver files and settings, and print as much as they want to all day long. In this scenario, the print job normally leaves the client workstation as an EMF (enhanced metafile) blob containing all of the necessary bits (fonts, images, printer settings) it needs to the print server, normally via an RPC (remote procedure call) connection. At the print server, the EMF is converted into whatever PDL (page description language: PCL 5, PCL 5, PostScript, HP-GL/2, etc.) is used by the printer driver. This type of arrangement has been working well since Windows NT 3.51 was released. In Windows 2008 with Vista or Windows 7 clients, the EMF is often converted to the PDL at the client, leaving the server very little to do except route the job to the printer through the designated port (this happens when the "Client Side Rendering" box is checked on the Sharing tab).
Some printer drivers do not support this type of workflow. In the industry, they are called "host-based" printer drivers. Host-based drivers are exactly what they claim to be: a driver that is installed on the computer creating the print file. In many cases, these drivers use a modified version of a common PDL, or they send data in their own, proprietary file format. Or, they utilize some type of communications path to the print device (as referenced by Roy earlier) that does not work well in a client-server scenario. One thing is common for all host-based printer drivers: they use a lot of system resources when they're creating their file, and this is normally what makes them completely unsuitable in a client-server environment like Pharos Uniprint (can you image if one print request consumes 5% of your CPU and almost 20MB of memory what 5 or 6 simultaneous print requests at a server would do?).
So how does this factor in to what our statement regarding plotter support is, then?Our statement is simple and vague at the same time:
Provided the driver utilizes a supported PDL (see https://pharos.custhelp.com/app/answers/detail/a_id/1074 for the latest list) and supports a client-server environment, it should work well within the Uniprint suite. Not exactly a cut-and-dried response.
Most plotter drivers, particularly those from Epson, are host-based drivers and must have a bidirectional communications path (either by connecting via USB/Firewire or via a direct TCP/IP path) to the print device in order to work, and because of the way a Uniprint package is installed (both in Windows and MacOS), bidirectional support is lost, so it won't work. In fact, if you look for a server-compatible driver on most wide-format plotter's manufacturer's websites, you will not find one. While Uniprint supports most PDLs out there, we still must operate in the context of a client-server configuration. So contacting the manufacturer's support group is a good first step, because if they support client-server, we should be able to support it in Uniprint. This takes me to David Marcinkowski's first post regarding RIP (Raster Image Processor) software (Re: Can you restrict the release station to release one print at a time?) By its very design, most RIPs must be client-server oriented, so their drivers for Windows and MacOS work very well in Uniprint. RIP software usually standardizes paper sizes to the classic "ARCH" ISO sizes, making them very easy to integrate with the Uniprint Job Cost Method.
I trust that the background provided creates understanding towards what appears to be an indirect statement of support of plotters within Uniprint.
Have a great day,
Pharos Systems Technical Support
The main issue with printer drivers and whether they work with Pharos seems to be whether or not they actually require installing some type of monitoring or tools software on the server. I've forgotten what that type software is, but it's something like "home" something. A lot of color printers out there like the HP 2600 utilize this type of driver installation package and Pharos won't work with it very well. You may want to check Epson's website and look for a universal type driver that will allow for auto device configuration through "Device Settings" under the Queue. That seems to play well with Pharos. Good luck
2 of 2 people found this helpful
In my experience, the Epson wide format devices work with Pharos (can be submitted and released to the devices without issue) but occasionally the Pharos page counter has trouble with some of the jobs detecting colour and page size. This appears to be a inconsistencies in the function of the driver rather than the Pharos page counter, where the same file when submitted from a MAC will count correctly but not from Windows and vice versa. These counting errors are most pronounced when using the Epson ESC PDL.
The real problem with incorrect page counting is that it leads to incorrect charging, which on a small A4/Letter printer doesn't cause much consternation, but on large format devices where the costs are considerably higher, users tend to jump and shout that bit louder....
As long as you are prepared that you will face these anomalies every so often, then you should have no other issues using them.
The Page Counter (Pharos Page Counter Hot Fixes ) has had improved support for the EPSON ESC/P2 format for several versions now, so if you can get your EPSON driver to send out that format from the client, charging is much better now.