Insufficient data for an image error in Adobe

[jeffp]

I have a strange issue.

In the attached zip file go to page 45 in the "AFTER" pdf file. If you open it in the ViewerX it is fine. But page 45 in Adobe gives and insufficient data for image error and won't display the page.

All we did with the "Before" pdf file to create the "After" pdf file was to place OCR text in it using your DLL calls.

Is there anyway you can tell what happened to page 45 that causes it to not render in Adobe? Was it something related to the way we placed the OCR text in it. Strange that it opens in the ViewerAX and not Adobe.

Thanks.

--Jeff

[KarlTH]

Hello Jeff,

I had the same error message on other documents in our company in Acrobat 9.4 and with Acrobat XI there was not any problem. Maybe it is because of the JPEG2000 compression?
It seems that older Acrobat or Adobe Reader versions have problems understanding the image compression.

Try the latest Adobe Reader version with all minor updates!
https://get.adobe.com/reader

Problem description from Adobes knowledgebase: Insufficient data for an image message after updating Acrobat
https://helpx.adobe.com/acrobat/kb/insu ... image.html


Best regards,

Karl

[jeffp]

Thanks. I'll look at that, but I still think it may have something to do with how I added the OCR text into the page. It only happens on page 45 and it doesn't happen in the original pdf, only after I add OCR text.

[KarlTH]

I am not an expert from Tracker Software but I had the same issues on ISO standard PDFs and the current Acrobat or Adobe Reader version always had no problems. Just give it a try!

[Tracker Supp-Stefan]

Thanks for the help KarlTH!

Jeff please do give it a try as suggested and let us know if all is OK with the latest Adobe versions?

Regards,
Stefan

[jeffp]

Latest version of Adobe still has the issue. What result to you get if you open the AFTER pdf with Adobe and go to page 45?

[Will - Tracker Supp]

Hi Jeff,

I see the same thing in the latest Adobe Reader and, in other Readers, see something slightly different (i.e. partial image rendering), though ultimately the same problem, I suspect.

Could you please provide sample code that details how you created the "After" file?

Cheers,

[jeffp]

My actual code is a bit complicated but essentially it creates a PDF page and places the OCR text using PXC_TextOutA and PXC_DrawText. It then adds that text to the original PDF using PXCp_PlaceContents.

Is there anything on the structure of that Page 45 that indicates bad formatting or something?

[Vasyl-Tracker Dev Team]

Hi Jeff.

The issue is reproduced and we will investigate and try to fix it. Thanks for report.

Cheers.

[jeffp]

Was it something in the DLL routines that place the OCR text? Or in your save to file routine?

Look forward to the fix.

[Will - Tracker Supp]

Hi Jeff,

Vasyl asked me to make a ticket for this - the number is RT-3067.

We appreciate your patience here!

Was it something in the DLL routines that place the OCR text? Or in your save to file routine?

I'm not a developer, so I'll have to leave that to Vasyl to answer.

Cheers,

[jeffp]

What do I do with the ticket?

Will you repost here once the fix is done?

[Tracker Supp-Stefan]

Hi Jeff,

The tickets are for internal use only, but use can use the ticket number to e.g. request an update.
As soon as there are any news in the ticket - we will post them here in the forums as well!

Regards,
Stefan

[jeffp]

Just wanted to get an update on this fix. My customer has been asking about it.

--Jeff

[Tracker Supp-Stefan]

Hi Jeff,

There hasn't been much movement on the ticket, so I've asked for an update. As soon as we have any further info we will let you know.

Best,
Stefan

[jeffp]

Will this issue be resolved in the new Editor SDK?

[Vasyl-Tracker Dev Team]

I checked - it looks like that it is fixed in Editor..

[jeffp]

But will it eventually be fixed in the non-editor components even if I don't get around to hooking up the Editor for a while.

[Vasyl-Tracker Dev Team]

Hi Jeff.

I just checked the latest version of Viewer ActiveX SDK and couldn't reproduce such problem. Can you check it again with latest version?
If it is still reproducible for you - please provide list of parameters that you using for OCR..

Thanks.

[jeffp]

This issue is still not fixed. Open the attached file in Adobe and scroll to page 33 and you will get the error again.

Just to reiterate. Page 33 opens fine in your ActiveX viewer. This is only an issue when opened with Adobe, but the file was created using your SDK Pro DLLs.

As mentioned before, my actual code is a bit complicated but essentially it creates a PDF page and places the OCR text using PXC_TextOutA and PXC_DrawText. It then adds that text to the original PDF using PXCp_PlaceContents.

I am using Build 4.0.313.1 of the DLLs.

Thoughts?

--Jeff

[Ivan - Tracker Software]

Can you provide original document before OCR ?

[jeffp]

Sure. Attached is a Before-After set.

On this set the issue is on Page 45.

--Jeff

[Will - Tracker Supp]

Hi Jeff,

Looks like the file was stripped. Please try uploading it in a ZIP folder or RAR/7Zip archive. If the file is too large, please send it directly to support@pdf-xchange.com, with a link back to this topic for reference.

Cheers,

[jeffp]

Here are the files separately.

Again, page 45.

[John - Tracker Supp]

Hi Jeff,

problem located and should be resolved in the next build mid month approx.

[jeffp]

Great. Thanks.

What build will it be so I know which one to look for.

[Will - Tracker Supp]

Hi Jeff,

The new build should be 314.

HTH!

[jeffp]

This issue has come up again.

Take a look at Page 21 in that zip file below. Again, the issue is when opening it in Adobe.

http://www.lucion.com/files/Example.zip

I'm on build .315

--Jeff

[jeffp]

Have you had a chance to look into this again yet?

[John - Tracker Supp]

Hi Jeff,

we are investigating this further as there is some odd content and properties of this document as it appears to have been created using our OCR libraries - but has PDF/A set has a flag and our OCR does not natively support this and when we delve a little deeper it appears it may have been made by some other method - perhaps you can throw some light on the subject ?

How was this file created and with what tools specifically ?

Thanks

[jeffp]

Your DLLs were used only to place the OCR content into the file. Earlier in this thread I mentioned the exact procedures I am calling. Your OCR engine was NOT used to create the file or get the OCR Text. I use an engine called TOCR that gives me the OCR text and word coordinates. I just use those coordinates and call into your DLLs to place the text.

Also, to clarify, the PDF is already in existence before I place the OCR text. Not sure what program my client used to create the PDF (or he may have received it in an email from someone else). But I just open the PDF with our DLL, place the OCR Text, and then resave it with your DLL.

Let me know if you need anything else.

--Jeff

[Ivan - Tracker Software]

Will try to reproduce it.

Do you reproduce that issue only on one computer or on different computers?
For now it seems like memory corruption during copying block of memory. And in all corrupted blocks, always sequence of 10 bytes is corrupted.

[jeffp]

It has been reported a few times by the same user. I assume that user is always using the same computer. It has never been reported by anyone else. And again, it's only when it is opened in Adobe, not your AX control.

Is there anything that can be done?

[Ivan - Tracker Software]

I don't know where to look for the problem, frankly.
This file is damaged, for sure, but it seem like a random damage, and it looks like that is hardware error.
Can you ask the customer to check on another PC?

And again, it's only when it is opened in Adobe, not your AX control.

As I said, the image is corrupted for sure, but the Viewer tries to decode as much as possible, while another app might stop decoding and report an error. it is implementation defined.

[jeffp]

What about this idea:

I see that the original file in this case was produced by Total Image ConverterX. When we do our OCR, we just place the OCR in the original file using your DLL calls. Then we save the resulting file out with the DLLs, which changes the PDF Producer to PDF XChange.

Would it help in anyway if, before I did the OCR stuff, I just opened the original PDF in either your DLL or ActiveX control and immediately saved it out. This would make the PDF Producer PDF XChange before I even begin the OCR placement.

Could this quick save as possibly help here in any way?

I've ask my customer to try it on a different machine, so I'm waiting to here back.

--Jeff

[Tracker Supp-Stefan]

Hello Jeff,

If the errors are repairable, a save as should fix them indeed, however there might be some errors that the Viewer/Editor can "ignore" and still display the content, but fixing them might be ambiguous, so in that case no fix will be applied, and that broken content could remain broken.

In your case the problem is with broken streams and unfortunately those will not be fixed by a "save as".

Regards,
Stefan

[jeffp]

But remember, the original PDF file, before I add the OCR text, is just fine. It opens fine in Adobe, all pages.

It is only when I add the OCR text and resave with your DLLs that the issue occurs. The last zip file I send has both the BEFORE and AFTER file.

ALso, currently I'm constructing a new PDF with all the OCR text for all pages and then using PXCp_PlaceContents to place the contents in the original file. Is it better to do this one page at a time, or is it fine to build all OCR pages and then call PXCp_PlaceContents once? Could that make a difference with this issue.

--Jeff

[Ivan - Tracker Software]

I don't think any of these will help as it seems that the problem is on the user's machine.
PXCp_PlaceContents copies content from a specified page of the source document and adds it to the destination page, and it moves all required resources (images, fonts, etc.) from source document to the destination one.
And this move is just a copy of the memory block, no decoding/encoding is done (in this case, because the documents are not secured).
And during the copy of that memory block some of them corrupted, and I do not see any regular pattern of corruption (like memory offset multiplied of some granularity, etc.), except that always 10 bytes of the stream are corrupted.

I would recommend first of all to test the memory of that machine, and also check if the problem is reproducible on another computer.