Limitcheck errors are caused by the complexity of the document, such as there being too many path elements in a line. This error is more common on old PostScript level 1 RIPs than on Level 2 or PostScript 3 devices.
Sometimes it is not the document that is too complex, but the RIP or printer has certain limitations.
Reduce the complexity of the file:
- In a lot of cases, redesigning the document to make it less complex can get around “limitcheck” errors.
- Breaking up the print job in smaller entities can also do the trick. Print only one page or even one color at the time. Send your page without including the images to see whether images are causing the problem.
- Ungrouping objects can be very effective. Often groups and especially groups in groups or rotated groups of objects really make it tough to render PostScript.
- Nesting files (e.g. placing an EPS in an EPS or placing a PDF file on a page) also adds to the complexity of a document and can lead to limitcheck errors (especially with the offending commands ‘save’ and ‘restore’).
- If you have a printer with a limited amount of memory you could try to reduce the number of fonts used in the document.
- Use the option ‘split long paths’ in drawing applications to split up complex path in easier to process chunks.
- If you are printing from Illustrator: if the document contains gradients, select Compatible Gradient Printing (Illustrator 7.x or earlier) or Compatible Gradient and Gradient Mesh Printing (Illustrator 8.0) in the Document Setup dialog box.
- Johan sent me an e-mail: He got a couple of limitcheck errors in PostScript 3 RIPs because of a very big ‘history’ entry in Photoshop EPS metadata. The problem is solved by deleting the metadata, but finding the offending image can be tricky in a big project. Photoshop itself has no problem with such EPS files and they can be placed in QuarkXPress documents without a problem. Using TIFF or JPEG or making it a standard procedure to remove history info from metadata (or all meta data) are valid workarounds.
Give your workflow, printer or RIP more room to work
- Lowering the resolution of your imagesetter or printer makes it easier for the RIP to calculate the job. This may seem odd but sometimes selecting a higher screen ruling is not such a bad idea as well.
- Reboot the RIP (or printer) to clear its memory.
- Some laser printers allow you to add more memory. That often does the trick and with the current RAM prices, it doesn’t even cost that much.
- If you are still using an old PostScript level 1 RIP, perform a font cache delete if you have the tools for this.
Avoid extra layers of software
- Get rid of all extra software that adds to the complexity of the job: do not use OPI, do not print using a printer queue, disable any extension or plug-in that adds stuff to the PostScript data, don’t download an error handler,….
Random characters as offending command
In QuarkXPress you can select ASCII or Binary data transfer to the RIP. If all our CMYK images are binary encoded, you should also select ‘Binary’ in the Page Set-up menu of XPress. If one of the images is ASCII encoded and you select binary transfer, you can get a ‘limitcheck’ PostScript error, offending command ‘(ÁEGD-**£12ze8’ (or other meaningless characters). Reopen all imagefiles in Photoshop, save them as binary files and print again in XPress. The problem will be solved. You could also keep the original images and redo the layout in XPress 3.11 or later as these versions of XPress are less scruffy about ASCII encoded files.
Limitcheck errors due to corrupted fonts
Another source of limitcheck errors are corrupted printer fonts on either the Mac, the server or the RIP itself. Try to find out if the limitcheck errors only occur with documents that share certain fonts. If this is the case, you should replace all those fonts with a fresh copy from the original disks.
Limitcheck errors due to insufficient memory
On laser printers, the limitcheck error can also mean that there is not enough memory to do the page size and resolution requested. A letter/a4 size page needs about 1 MB at 300 ppi, 4 MB at 600 ppi and 7 MB at 800 ppi. Double these requirements for A3/11×17 paper. Double again for duplex (double sided printing). Quadruple for color printers. This is just to hold the page; more will be needed (at least 1 MB) for fonts, paths, and other things.
Niknak causes limitcheck error
PDF files created by Niknak version 1.1 Patch Level 2 can cause limitcheck errors when printed from Exchange to an Adobe RIP. This was fixed in patchlevel 3 of Niknak.
More detailed information
There are several commands that can cause limitcheck PostScript errors. Check the specific offending command to get a more detailed error description: addglyph, clip, fill, findfont, image, restore, save, sethalftone, setscreen, show, stroke.
9 thoughts on “PostScript error: limitcheck”
This error normally indicates that the file is correct but it exceeds the implementation limits of the RIP. However, excessive resource consumption can be also caused by infinite loops or recursion. Little can be determined without a sample file.
Please contact Coscript Consulting for professional resolution of PostScript and PDF issies: [email protected] or +1 (610) 529 3475.
My Error: Limitcheck…….STACK: /CIEBaseABC -dictionary-….
Printer: Fuji Xerox ApeosPort-IV C4470
Driver: Xerox GPD PS V2.2
Fix: Go to Printer Properties -> Advance Tab -> UNCHECK : Enable Advanced printing features
At least, disabling this fix my issue.
I m having this error on a 4700 color laserjet network printer. It starts spitting out pages non stop with this error.. anyone has an idea if this is software or hardware. Also I have all latest driver and firmware updates.. driver I am suing is PCL6.. any help would be appreciated
very interesting article.
I am getting an error:
PS limitcheck error, offending command “setpagedevice”
Anybody have an ideea?
Sometimes the easiest way to removed embedded control sequences is to copy and paste the affected section to notepad, tidy up the text you want preserved, then copy and paste it back.
The affected text will p;obably need to be tidied up afterwards to make it consistant with the rest of the text but an effective way to remove unwanted (and unseen) sequesnces.
I am getting this post-script error also…
I am creating publishing PDFs from a WORD document and uploading them to our site.
I have no problems printing them with the HP2840 Color Laser Printer from the file kor from the website. My boss can’t seem to print them either from the transfered file (from my computer to his) or from the website.
He is running Windows 7 with Office Suite 2007.
I’m running Vista 64-bit with Office Suite 2007.
I even tried publishing the file from his WORD.
He has had clients also contact him saying they were have problems printing the PDFs also.
Do you have any clue what is going on?
Thanks in advance!
Interestingly, I’m currently getting a limitcheck error on an HP4700- less than 2 years old! >Our now defunct 4600 never had this issue when printing the exact same file!
Back in the olden days (meaning: 10 years ago) printservers would often have their own set of data that would be appended to every printjob, essentially increasing the complexity of the job. That was sometimes enough to make a device run out of memory. I don’t know if it still makes much of a difference nowadays.
This is a good article about Postscript limitcheck errors. I do have one question, however. You say not to print using a printer queue. Could you explain your reasons?
I work in a prepress environment and have used a Panther RIP running on a Mac G4 in Mac OS 9.2.2. It worked fine except for in-RIP separations, which would crash the RIP software if we left the preview window open. We were told that the RIP software was not fully compatible with the OS version we had installed (recommended is System 7.5).
Several months ago, I replaced the G4 with a Blue & White G3 and installed OS 8.6 to see if that would correct the issue. Unfortunately, the problem still existed, and a new problem developed. When printing two jobs in sequence, the first would print fine and then the second would die with a random Postscript error. I have not been able to figure this one out, but now I think it may have to do with our printer server setup.
I use a Powermac G4 running Mac OS 10.4.11 as my main prepress workstation. We have another G4 running Mac OS 10.3.9, serving as a print server for a our Imagesetter as well as a LaserJet. Print Jobs stack fine in the LaserJet queue, but the imagesetter’s queue exhibits the issue above. Bypassing the print server and printing directly to the imagesetter does not solve the problem.
I can get all the print jobs to image correctly if I place the print server’s job que on hold, spool several jobs, and then release them one at a time, when the imagesetter finishes the prior job.
If you could shed some light on the subject and offer some possible solutions, it would be appreciated.