🚀 go-pugleaf

The manufacturer (or at least this particular representative) has made the same claim several times in a forum in which I participate. Another paraphrase "you seem to be relying on the RIP to cache. PaintProc is always re-executed, that's why we came up with our solution".

The implication is that you cannot rely on "plain" PostScript, and must buy their application in order to reap any performance benefits when dealing with reusable content.

So the implication is definitely "any other vendor who uses an Adobe RIP won't cache forms... we're better because of our unique 'fix' to the problem".

I haven't replied to the claim because I don't have the facts. I've read the Adobe TechNote #5113 "Emulation of the execform operator", it says "During its first execution, the form can be cached in a manner similar to the caching of PostScript language fonts. This allows for the fastest possible rasterization of subsequent invocations of the form." It says "can be", not "is".

Another quote: "The first instance of execform (called using EF)validates the form dictionary and makes it read-only. It then calls the PaintProc to paint the form. The subsequent executions of
execform paint the form by either invoking the form�s PaintProc or by substituting previously cached output."

This all makes sense. RIP developers must choose how or if they will support caching. Like you've mentioned, what would be the point, for example, with Distiller?

Still, I'm asking specifically about Adobe RIPs, and even more specifically, the CPSI sold to OEMs. Does it itself provide for caching?

Do you recall the technote you mentioned? Is it the same one I referred to above?

Thanks,

Thomas D. Greer
 <http://www.tgreer>