NEW ERROR: t5::corrupt_data in the PDF Embedded API viewer

[Marci29953097d1ua]

Our viewer newly reports:

index.js:1 Exception: t5::corrupt_data,

The PDF is fetched through a URL. I can use the same URL to download the pdf and load it into Preview, Google Drive, Foxit viewer, etc.

And I can see that there was recently a new release:  https://developer.adobe.com/document-services/docs/overview/pdf-embed-api/releasenotes/#may-2023

Is there something we need to change on our side to get this working again?

Thanks in advance

[Marci29953097d1ua]

I verified in ChromeVersion 113.0.5672.92 (Official Build) (x86_64) on Mac OSX.

[Marci29953097d1ua]

Update: It looks like an issue on my side. I tried hard coding the url to the adobe sample pdf "https://acrobatservices.adobe.com/view-sdk-demo/PDFs/Bodea Brochure.pdf" and with that url the new viewer does not have a problem. 

Any recommendations for a good PDF validator tool?

[kglad]

in the future, to find the best place to post your message, use the list here, https://community.adobe.com/

p.s. i don't think the adobe website, and forums in particular, are easy to navigate, so don't spend a lot of time searching that forum list. do your best and we'll move the post if it helps you get responses.

<moved from using the community>

[Petar29954215mu76]

I'm having the same problem, CSP and CORS issues, that I've never had in the past.

The fact that @Marci29953097d1ua is able to render a document under adobe's subdomain could indicate the potential issue that something changed at Adobe's side. Is it possible that the CSP being violated is set by Adobe itself?

[Test Screen Name]

We don't know anything about the embed API. You need a different group of experts, and you will find them at -- Acrobat Services API - Adobe Support Community

[kglad]

<moved from acrobat>

[Marci29953097d1ua]

Thanks for moving this for me.  Apologies for posting to the wrong place initially. 

[Marci29953097d1ua]

After more testing I have verified that this the viewer does not like the bits in the pdf.  I tried with the adobe sample pdf and it works fine.

However, I'm still trying to sort out why it doesn't work now with the PDF'S that it used to work with just recently.

Is the new version of the viewer more strict with regards to the validation of the pdf?  

We are using Aspose PDF to programmatically build the PDFS and they were working without issue up until recently.

Thanks for any help you can provide.

[Basil21899888i05k]

Has the same issue which seems related to the digital signature fields available in a document.

[Marci29953097d1ua]

More detail: Here is what shows in the developer console:

t5::corrupt_data
    at ___cxa_throw (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:28684)
    at self.___cxa_throw (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:206)
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.wasm:wasm-function[676]:0x57969
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.wasm:wasm-function[5024]:0x3c4462
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.wasm:wasm-function[10257]:0x5c1332
    at invoke_viii (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:103321)
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.wasm:wasm-function[4787]:0x386e29
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.wasm:wasm-function[9497]:0x503c48
    at Module._eventHandler (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:82931)
    at ccall (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:79063)
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/wasm_acrobat.js:1:79368
    at be (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/acrobatProxy.js:2:79868)
    at Ae (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/acrobatProxy.js:2:83764)
    at we (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/acrobatProxy.js:2:85868)
    at Se (https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/acrobatProxy.js:2:85552)
    at https://acrobatservices.adobe.com/dc-rendition-provider/3.0.2_5.4.0/AJS/acrobatProxy.js:2:85830

[Basil21899888i05k]

The same.

[Marci29953097d1ua]

Just wondering if the new viewer has any documented or undocumented configs that might affect this issue.  Like a 

workJustLikeThePreviousVersion:true

or 

strictMode: false

[Marci29953097d1ua]

Update:

We tried nearly all of the configuration parameters as we could and still never got the viewer working again.

This was failing on our production system so we had to go ahead and completely remove it. 

[Marci29953097d1ua]

... I'm not saying there is a bug in the viewer. It seems to handle many / most PDF files with no problems. It is just that the new viewer no longer supports the PDF files that we have been producing for years which have also passed many validators.  But there is obviously something in our PDF's that the new viewer does not like.  We just didn't have time to get to the bottom of it.

[Basil21899888i05k]

As a workaround we found that opening the file in Adobe Reader and saving again may help.

[Basil21899888i05k]

Well, updated the underlying iText libraries to the latest version (8.0.0) and it seems fixed the problem.

The most annoying thing in this case is absence of exception reason and support from the Adobe SDK/team.

[kglad]

@Basil21899888i05k 

thanks for posting your solution.

[Basil21899888i05k]

Unfortunately, it is only a partial solution. Thousands of old documents stay unviewable. I hope to see feedback from the Adobe dev team about fixing the issue. At least in release notes.

[David29604995gl7b]

We're having the same issue and I agree with you. We have PDFs which come from many different sources and they need to be visible.

[Jagjit26083403cjd9]

Am facing the same issue. As a fallback, i used a timeout to render the PDF in an object using the default browser PDF rendering

[sjf7800]

I also have this issue seeing ERROR: t5::corrupt_data. Some PDFs work and some dont. When looking at the PDFs that get the error I see they have fonts that are not embedded. Maybe another direction to look at. Maybe the API trys to fetch non-embeded fonts and it throughs the error. I will implement your idea of a timeout as seems a sensible approach to issue will Adobe can tell us more.

[kglad]

these are user forums.

if you want to give feedback to adobe, 

for applicable apps, you can make (some) suggestions to adobe here, https://helpx.adobe.com/ie/x-productkb/global/how-to-user-voice.html

for others, use https://www.adobe.com/products/wishform.html

[DeanWa]

What are you using now? Having major issues here. Tried using a normal html embed but iOS can't cope with more than one page.

[Jagjit26083403cjd9]

I am using regular JS on a timeout and a flag to check if adobe successfully rendered the PDF if not, use the base 64 data string of the PDF into the src tag of a backup IFrame container

  const iframetTag = document.getElementById(_this.renderingContainerId + "_iframe") as any;

                                if (iframetTag ) {

                                    iframetTag .src = (_this.attachedFile?.dataString || "").replace("application/octet-stream", "application/pdf"); 

                                }