This is a very general question but it’s based on a specific problem. I’ve created a pdf reader app for the iPad and it works fine except for certain pdf pages which always crash the app. We now found out that the very same pages cause Safari to crash as well, so as I had started to suspect the problem is somewhere in Apple’s pdf rendering code.
From what I have been able to see, the crashing pages cause the rendering libraries to start allocating memory like mad until the app is killed. I have nothing else to help me pinpoint what triggers this process.
It doesn’t necessarily happen with the largest documents, or the ones with the most shapes. In fact, we haven’t found any parameter that helps us predict which pages will crash and which not.
Now we just discovered that running the pages through a consumer program that lets you merge docs gets rid of the problem, but I haven’t been able to detect which attribute or element it is that is the key. Changing documents by hand is also not an option for us in the long run. We need to run an automated process on our server.
I’m hoping someone with deeper knowledge about the pdf file format would be able to point me in a reasonable direction to look for document features that could cause this kind of behavior. All I’ve found so far is something about JBIG2 images, and I don’t think we have any of those.
Same issue encountered with two ‘special’ PDFs that couldn’t be rendered on an iPad app or Safari for iPad. In my case, the problem was isolated to some semi-transparent gradient shades.
By the way, converting the PDF to postscript, and then back to PDF again, seems to remove the internal elements that PDFKit doesn’t like. The original document was 1.9 MB in size with lots of vector shapes, after the conversion process the file reduced in size to about 600 KB, and was rendered flawlessly on iPad.