form cache 1

[tomte]

Are there instances where the Adobe rip does not cache the static form, but rips the image data with each new data set in a VDP application. I have several forms created by a commercial VDP application that on some Adobe rips process with lightening speed and on other Adobe Rips choke down the interpreter. Since the postscript is consistant, I am led to believe that it is some setting at the rip itself that is causing the issue. Both RIPS are licensed from Adobe. Are there configuration settings that could cause this behavior? The forms are fairly simplistic. Bitmap images are stored as the static form information, with text data being in the record sets that overlay on top of the bitmap images. These images could be EPS, TIFF, BMP, or PDF and the behavior is consistant. Does anyone have an idea of where I might investigate why I get such radical differences on what should be at it's core the same Adobe RIP?

 

[tgreer]

I've seen problems with forms if

1) You do a lot of changes to the graphics state between execforms... the RIP essentially says "I can't trust what I have in the cache anymore, too much has changed" and so re-rips the form.

2) the RIP doesn't have enough memory.



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[tomte]

The particular files I am using to test are simple bitmap overlays 300dpi on a 600 dpi printer. When I look at the code generated by the program (and I am not a postscript programmer yet) it appears to be a properly cached form page. If I send the file to a harlequin rip on a wintel system it processes with blazing speed. When I send it to the Adobe rip the file slows to a complete crawl. It is a Level 3 interpretor, running 128mb ram with 90 mb allocated to the postscript interpretor. I have form cache minimum set to 1000000 bytes and the form maximum set to 40000000 bytes. It seems as if the rip is processing the bitmap image with each form iteration. I have corrected the bitmaps for proper scan orientation to the rip for the size paper (letter in this case, side to side orientation) (paper feeds long edge on the printer) This behavior seems to be consistent regardless of the variable data design package I am using PlanetPress, PrintShop Mail, samples from the ps forums, Red Titan, and a couple of others.

 

[tgreer]

You've done a thorough job of testing, it might be time to contact your RIP vendor/hardware vendor for support.

Level 3 Rips should also be able to RIP PDFs natively. PDFs have an analogous way of dealing with forms.

That is, you can take a PostScript program with forms and distill it to a PDF, and the PDF will be effecient, only including the form image once and using it by reference.

So for further testing: take your PostScript, run it through Acrobat Distiller to create a PDF (this should be very fast). Then RIP the PDF and see what performance you get.

Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[tomte]

Thanks Tom for all your support. Unfortunately the way this PS3 rip functions on PDF files is that it renders the PDF to a temporary PS file then processes the PS file. Back to the same performance issues. I thank you for your time. I was hoping that there might be some undocument tweaks you could perform to the RIP itself with a configuration setting. I do have access to some configuration files for the rip on the machine, but not sure how they affect the performance.

 

[tgreer]

That doesn't sound at all right. If it's a genuine Adobe Level 3 PostScript RIP, it should certainly process PDF files without going to PostScript first!!



Thomas D. Greer

http://www.tgreer.com

Providing PostScript & PDF
Training, Development & Consulting

 

[tomte]

Background hacking. Since the rip is a software rip from Adobe, I have watched it build this temporary ps file that it actually uses. It was interesting the reason I stumbled on it was because the machine choked on a file that was over 2gb in size in this rip state, but was only 200mb in pdf state.

 

[david63]

If you are using PlanetPress, try out their "grayscalepdftoeps" utility, available from their download site (which will work as long as you have a licensed version of their design tool installed). This software has helped me out quite a bit with what is probably the same rip you have spoken of.

If I may ask - have you made any inroads using Red Titan -- this is one that I have had no luck in improving the rip speed with, either. Have you checked out the EPS files that their "Red Print" software makes and uses as the form overlay inside the PS files? I try to distill them and they appear as blank-page PDFs, probably becuase of a routine in the PS (separated from the EPS) that converts them. I have tried a few ways to incorporate those scripts into the EPS itself, but have not been able to get the images to appear so I can turn them on their side.

 

[GolanTrevize]

Genuine Adobe RIP's don't process PDF files directly (Harlequin and Jaws do), the PDF is converted into PostScript internally and the result is sent to the RIP.
I prefer Adobe's approach since you can continue using PostScript procsets inside the RIP to work on both PDF and PostScript data.

Golan