Greetings Elmo3 and Patrick,

Alright, time to move the tangent to it's own thread. I am curious, not knowing as much about the EFI offering but always thinking it was silly to put a rip before a rip and to spend the extra money, what does it improve. What problems does it fix that solutions like the creo do not?

The whole APIA workflow through the DocuSP solves a very big problem for workflow developers: cost of developing something to drive the iGen3. With the APIA bitmap spec laid out, Xerox can do anything they want to the iGen and simply adjust the DocuSP as needed. Third party developers can be blissfully ignorant of such changes, and simply continue to create a bitmap that meets the APIA spec. That is MUCH cheaper than the development costs involved in creating a RIP that drives the engine as the engine evolves.

And that's what the EFI piece is--a workflow piece. Some people are heavily invested in EFI technologies, and they want to leverage those technologies and training and people resources. What was Xerox going to do--tell the Canon shop who wants to move up that "no, we won't give you Fiery, you must learn our DocuSP no matter what!"? And then EFI bought PrintCafe; their MIS customers can now easily plug a Fiery into their MIS.

But suppose someone like Rampage, for example, wants to plug into iGen3. I know their customers are very loyal, and would love to apply Rampage workflows to the world. APIA makes that possible (this is just an example). Rampage could create something that makes an APIA bitmap and just send it off, treating the iGen3 as just another shooter. If Rampage had to drive the press directly, it could never happen.

That's just a possibility, but there are good uses for the APIA workflow. There's nothing wrong with preferring a different color correction mechanism than what DocuSP offers, and plugging such a color correction box into the iGen without it having to drive the iGen directly.

APIA needs more development, and it's underused. The two feed off each other in a vicious cycle.

Maybe DocuSP will get all the features that the other vendors are successful with. They're working on it; 2.4 sees hot folders, post-RIP imposition, and imposition of VI streams. Until that happens, there are plenty of reasons to want a non-DocuSP solution that's flexible enough to stay abreast of the customer needs. EFI and APIA can do it. So can others, if they want to.

But yet, correct me if I am wrong... APIA interface and using an EFI DFE, still requires you to calibrate the DocuSP and then calibrate the EFI DFE?

As for the "improved" imposition, I have to give that to EFI for now, but a simple copy of Preps can do it for far less.

As for VPS, correct me if I am wrong, but even EFI doesn't officially state they can do VPS binary or actually cache VPS. So its no faster then postscript. Also, EFI doesn't have v2 vps support.

I agree that the APIA interface is a great option for the DocuSP and future development with workflow solutions such as Prinergy (doubtful since they already have a DFE, Spire), Rampage and Prinect to connect to it.

I just don't see the EFI solution as a workflow connectivity, there is no JDF / JMF pathway, its just a pre-rip. If you could hook up multiple EFI rips up stream and pre-rip VI streams or something, then maybe it would be worth it.

On top of it, from the sounds of it, as you stated, 2.4 seems to strengthen the arguement for only a DocuSP and finally adding features that have been common since day one on the Creo.

I think the only real reason for an EFI solution in front of the DocuSP is for user simplicty. EFI has always been a very simple, easy interface that lots of people know. DocuSP has a very complex and not so user friendly interface. Puting EFI in front allows for a faster transition for those that don't want to learn the complexitities of DocuSP. Yet, they still do have to do some things on the DocuSP, unless they've made it completely headless.

Also, have they finally got more then one job spooling at a time? Or can you only send one job from the EFI through APIA?

Also, do you actually use EFI in a printing environment or are you someone who works for EFI / Xerox? I'd love to hear from someone who actually uses the EFI solution and their thoughts.

I am sure there are benefits beyond this... As for the EFI Truck, they were too busy trying to show me the workflow options, and since I had a Creo already, they couldn't come up with anything above and beyond what I already had.

Calibrate the DocuSP: yes. Calibrate the Fiery: never. The Fiery makes color correct bitmaps and sends them through the DocuSP, where calibration is applied.

EFI has full, current VPS support--and Xerox backs it up. That's different from when you were here.

I agree, Xerox needs to use APIA to do a multiple off-line RIP solution. There are plenty of Creo customers, for example, who would buy into that (unless Creo has their own off-line multi-RIP solution).

The *only* thing the user needs to do on the DocuSP is calibration. If there's a DFA device, the finishing profile is set up on the DocuSP but is called from the Fiery.

Yes, so far it's one job at a time. Streaming, not spooling.

So EFI has the ability to cache VPS elements and use them across job boundaries, archive and restore them?

Also, how is the EFI solution when it comes to optimized PDF or PS workflows? Does it still need to dump the PDF out to postscript, ala decompose it, and rip it one page at a time or will it respect xobject level caching?

What about job recovery? How does the EFI solution handle job recovery, or is that all handled at the docuSP?

How about large variable jobs on it? Is there a bottleneck in the streaming of the data or any delay in printing? Can APIA start printing immediately and stream or does it need to recieve the whole file before it starts? I know docuSP can start printing immediately, but not aware if the EFI solution can take advantage of that or if that's a limit of APIA?

As for Creo with HP Indigo, they are working on a pre-rip like scenerio, no idea if that will make it to the iGen3 world.

Don't get me wrong, I think that the DocuSP's APIA interface is a great solution. I just have a hard time justifying an EFI rip in front of the DocuSP from my perspective with DocuSP or Creo directly, able to do all the things a printer needs to do on a front end.

APIA should and Xerox will hopefully move it to be used as a workflow enablement pathway. If you consider EFI's front end a workflow in itself, then the EFI DFE is a good solution for you to go through APIA. However, the potential for APIA goes well beyond EFI and could be tremendous for pre-rip / cluster rips down the road.

I think the best arguments for EFI so far include:
1. Simple user interface
2. Common interface (look and feel) to EFI workflows.

It is important to provide a solution that fills this niche and integrates into the look and feel of greater offerings; however, I do not see any benefit for the typical commercial printer.

I keep beating my head up against the fact that simplier is always better. Experience has demonstrated that 1 rip equals lots of problems. I cannot help but think that 2 rips equals more problems. I don't fix an engine problem in my car by installing a second engine in the trunk.

Job elements across boundaries: I don't think so at this time.

xobject level caching: I believe so. I don't think it's processing PDF to PS. (DocuSP, though...)

Job recovery is seamless, with the communication between the Fiery and DocuSP. The APIA queue is a streaming queue, and it starts printing immediately. Long VI jobs are no big deal.

Cluster RIPs--absolutely. In this day and age of huge VI runs that are badly created (one guy does everything fat PDF because he likes to be able to open the fiile and see it), cluster is a nice solution.