error: typecheck offendingcommand: renderbands

meddington

Well-known member
Getting an error from Navigator 8 rip. The file is from Esko Backstage 7.4, PDF v 1.7. I've read that gradients from non-standard apps can cause this issue, but does anyone have any suggestions on rectifying? Adjusting levels of gray and increasing memory have no effect.
 
What's wierd is I can turn off the spot colors (in the separation parameters) and the 4/c will Rip. Wierder still, if I select HDS-Med screening (stochastic) I can Rip all separations. But 150 Euclidean with all spots generates the error.
 
I had a lot of similar issues (and still have) with Navigator 7.2.
If you can rip without trapping, it will certainly go through.
Otherwise, try just restarting Navigator. It helps in around 4 of 5 cases. I guess it's some kind of memory management issue with TrapPro.

Oh and jobs with live transparency that covers the whole page or a smooth shade trigger this nearly every time; the only viable solution I found was to flatten transparency with Acrobat before trying to rip these files.
 
What are the specs. of your RIP box? If you have a newer PC with 4GB of RAM, have you added the switch ( /3GB /USERVA = 3030 ) to the Boot.ini file to allow the RIP to use 3GB of the RAM for the application? You can also install Service Pac 3 to accomplish the same thing.

Look at the ConfigureRIP file in the SW/Config folder to see how much memory the RIP is utilizing. The line /MaxAddressSpaceSize should read 3xxxxxx. You can also check it in the RIP by looking at the Memory Statistics. It should read more than 2GB.

***If you have Service Pac 3 installed, DO NOT put in the switch. It will cause the PC to not boot.***
 
>The line /MaxAddressSpaceSize should read 3xxxxxx.

It does indeed.

> time; the only viable solution I found was to flatten transparency with Acrobat before trying to rip these files.

Yep, that works. Doesn't explain the anomolies, or help our workflow, but it works.
 
If you have been pounding the RIP for awhile, you may want to defrag the hard drive. The newer computers have large enough drives that this should not be a problem, but it won't hurt. Also check to see how the virtual memory is set. Even if you have 3 to 4GB of RAM, XP seems to want to set this very low. This could cause the RIP to have to right to the hard drive for large complex files, especially with trapping and this could cause an error. Make sure it is set to at least 1.5 times the actual RAM, or change the setting to let the system handle it and it should fix the amount as such.

If none of the above help, I would say that you have found an issue that hopefully will be addressed by Global Graphics or Esko if they can figure were the problem is.

There are always going to be issues with some files and a work around is necessary. If anyone says their solution is a wonder workflow and will work with ALL files, run, and run fast and far...............
 
>The line /MaxAddressSpaceSize should read 3xxxxxx.

It does indeed.

> time; the only viable solution I found was to flatten transparency with Acrobat before trying to rip these files.

Yep, that works. Doesn't explain the anomolies, or help our workflow, but it works.

Can you try to RIP without trapping enabled? If this works, too, you should contact Xitron's support for this trap-problem. Good luck though, they never came up with a solution for me.
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top